Deep Dive 210 – Vision to Act Pyramide mit Paula Ostmann

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

Die To-Do-Liste quillt über, das Postfach platzt aus allen Nähten und das Gefühl, permanent im Stress zu sein, gehört schon fast zum guten Ton.

In unserer neuen Deep-Dive-Folge haben sich Dave und Dennis direkt von der DecompileD-Konferenz Verstärkung geholt: Paula Ostmann, Engineering Managerin bei elevait, ist zu Gast und spricht über ein Problem, das wohl fast jedes Tech-Team kennt – die permanente Überlastung. Unter dem Titel „There are no awards for being the busiest“ erklärt Paula, warum blinder Aktionismus uns nicht weiterbringt und wie wir stattdessen lernen, die richtigen Prioritäten zu setzen.

Wusstet ihr, dass der Schlüssel zu einem entspannteren und gleichzeitig erfolgreicheren Arbeitsalltag in einer klaren Struktur liegt? Paula stellt uns ihr selbst entwickeltes Framework vor: die Vision-to-Act-Pyramide. Dieses Modell hilft Teams dabei, eine durchgehende Kohärenz von der übergeordneten Mission bis zum täglichen Doing im Backlog aufzubauen.

In dieser Episode erfahrt ihr, warum es so wichtig ist, immer beim „Warum“ – also der eigenen Mission – anzufangen. Es geht darum, wie man aus einer klaren Vision messbare und erreichbare Ziele ableitet, statt sich mit zu vielen Projekten zu verzetteln. Erfahrt, wie eine Roadmap als strategisches Kommunikationsmittel funktioniert und warum sie Kapazitäten für Unvorhergesehenes wie Support oder Bugfixes zwingend berücksichtigen muss. Paula präsentiert außerdem drei goldene Regeln, um zeitliche Kohärenz zu wahren und flexibel auf externe Veränderungen zu reagieren. Zuletzt klären wir die Frage, warum High Performer oft diejenigen sind, die besonders gut darin sind, auch einfach mal „Nein“ zu sagen.

Egal, ob ihr euer eigenes Zeitmanagement optimieren oder die Zusammenarbeit in eurem gesamten Team auf ein neues Level heben wollt – Paulas pragmatische Ansätze bieten jede Menge Inspiration.

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_03 0:08

Hallo und herzlich willkommen zu einer neuen Deep Dive-Aufnahme der Programmierbar. Ich grüße euch gerade hier aus dem schönen Wodafuren-Gebäude in Dresden, wo wir netterweise unterkommen durften. Sehr schönes Büro, die Sonne scheint, es ist wirklich herrlich hier. Wir werden heute in unserem Deep Dive über Teams reden, DevOff-Teams, Microsoft Teams. Was deren Herausforderungen sind, wie wir das Richtige zur richtigen Zeit bauen können. Direkt zu meiner Linken ist der Dennis Becker. Hallo Dennis, schön, dass du da bist. Schön, dass ich hier sein kann. Und wir haben uns natürlich ein Profi mit ins Studio geholt. Dave Kuschitski.

SPEAKER_02 0:54

Das ist der Profi. Sorry. Also alles gut. Wir schneiden gar nichts raus, wir machen einfach weiter. Wir machen einfach weiter? Ja, denn, liebe HörerInnen, das war Dave's erstes Intro in einer Deep Tive-Folge. Das war bisher ganz gut. War bisher ganz gut.

SPEAKER_03 1:07

Bis auf dass du deinen Namen vergessen hast. Ich habe meinen Namen vergessen. Oh, ich habe meinen Namen vergessen. Yo ich bin natürlich Dave. Dave Kuschitzki, moin. Und neben mir sitzt die Paula. Hallo Paula, schön, dass du da bist. Hallo, schön hier zu sein. Paula, um einfach mal ein bisschen für die Zuhörerinnen jetzt klarzumachen, wer du bist, magst du dich mal kurz selbst vorstellen?

SPEAKER_00 1:24

Ja, also ich bin die Paula Ostmann, komme aus Dresden und bin Engineering Managerin bei Elevate. Und ganz ursprünglich bin ich eigentlich Physikerin. Also ich habe Physik studiert und in Physik promoviert.

SPEAKER_03 1:37

Wenn ich erstmal ein spannender Werdegang von Physikstudium zu jetzt Engineering Manager, kannst du den Weg hier kurz näher bringen?

SPEAKER_00 1:45

Skizzieren. Ja, also in der Physik, also vor allem habe ich in theoretischer Physik promoviert, das heißt, das ist theoretisch. Man experimentiert nicht. Also alles, was man macht, rechnet man. Und man kommt natürlich sehr schnell an die Grenzen von dem, was man mit Stift und Zettel ausrechnen kann. Das heißt, man simuliert auch sehr viel und programmiert viel. Also eine gewisse Matlab.

SPEAKER_03 2:03

Und Matlab kenne ich auch noch.

SPEAKER_00 2:04

Matlab kann man nehmen. Ich war so ein bisschen, also ich habe alles in C ⁇ gemacht. Aber man kann natürlich Matlab nehmen oder Python wäre eigentlich so die Wahl für die meisten Physiker. Genau, ich bin da abgetriftet. Wer weiß. Also dadurch hatte ich so eine gewisse Nähe zu dem Thema. Und wenn man sich dann entscheidet, nicht mehr in der Physik oder in der Wissenschaft zu arbeiten, muss man sich entscheiden, was man machen möchte. Und so ging dann der Weg in die Software, in den Softwarebereich. Da habe ich erst als Systemingenieurin gearbeitet und dann ging das so in diese ganze Teamleitungsrolle. Und jetzt bin ich Engineering Managerin.

SPEAKER_02 2:40

Ah, okay. Und was macht ihr bei Elevate?

SPEAKER_00 2:44

Wir automatisieren Arbeitsprozesse, die sich sehr, die eben sehr wiederholbar sind, sage ich jetzt mal. Also wir haben große Kunden, die viele Daten haben, die so von vielen Kunden kommen. Also der klassische Fall ist, wir arbeiten mit einer großen Bank zusammen. Das heißt, die haben viele Kunden, die sich für einen Kredit bewerben oder die eben sagen, hier ist meine, ich möchte meine Adresse ändern oder irgendwelche Daten eben schicken dahin. Und oft müssen die Firmen das noch selber irgendwo eintragen in die Systeme. Es ist so halb manuell. Und das können wir automatisieren, weil es ist ja sehr repetitiv. Also es kann ich ja einfach, es ist nicht einfach. Aber ich kann das eben automatisieren. Und das machen wir mit AI, weil wie sonst. Und genau, also wir nehmen diese Daten, extrahieren die, packen die in die Systeme, die sie eben nutzen und wir machen auch noch mehr, aber das ist so die Kernidee.

SPEAKER_02 3:38

Ist das AI, wie nennt man das? Native, AI First, AI, also wie lange gibt es das Unternehmen schon?

SPEAKER_00 3:46

Das Unternehmen seit viereinhalb Jahren.

SPEAKER_02 3:49

Ah, okay. Klingt fast sogar nachher. Aber ist der Native ist das in dem Namen von Elevate. Achso, du guckst jetzt schon. Sorry, ich gucke dir jetzt, weil da steht ja Elevate GmbH und da steht, das wird ja anders als das Elevate geschrieben. Ist das schon Absicht, dass da AI drints steht? Genau, ja. Okay, also das war es schon vor viereinhalb Jahren so.

SPEAKER_00 4:06

Ja, genau. Es war so gedacht.

SPEAKER_03 4:07

Ich dachte mir coole Schreibweise, aber hab's gar nicht unterfragt.

SPEAKER_00 4:10

Genau, das AI steht für AI.

SPEAKER_03 4:13

Das ist ja super schlow.

SPEAKER_02 4:15

Dann war ja auch schon ein recht bolder Move, oder? Vor viereinhalb Jahren, na gut. Ja, trotzdem, aber ja, okay.

SPEAKER_00 4:22

Ja, also ich glaube, die Genese der Firma geht noch ein bisschen weiter zurück. Also es gab eben noch Projekte vorher und so weiter, aber genau, man hat ja recht zeitig auf eben Machine Learning gesetzt und auch Knowledge Graph, falls das auch ein Begriff ist. Das sind so die zwei Bausteine.

SPEAKER_02 4:39

Okay. Und du bist da seit einem Jahr.

SPEAKER_00 4:41

Einem Jahr. Genau. Okay.

SPEAKER_02 4:43

Und da wir ja ein bisschen über so Teamstrukturen und Teams sprechen und sowas, ist wahrscheinlich auch interessant, so ganz kurz mal, wie groß ist im Moment Elevate? Für wie viele Leute bist du verantwortlich?

SPEAKER_00 4:54

Also Elevate selber ist ungefähr sind wir 100 Leute, verteilt auf zwei Standorte. Also wir haben noch einen Standort im Schwarzwald, in Triberg. Und die meisten sitzen aber in Dresden oder remote, wie das eben so sich verteilt. Vielleicht mal kurz zur Struktur ein bisschen. Also wir haben so den, es gibt so diesen Business-Teil CS und so weiter. Und dann gibt es den technischen Teil, wo wir die Entwickler-Teams haben. Ich muss nochmal zählen, ich denke, wir haben elf Entwickler-Teams, so ein bisschen angelehnt an Team-Topologies. Also wir haben versucht, diese Stream-Align-Teams für die Produktentwicklung zu machen. Das sind die Feature-Teams. Wir haben ansonsten noch Application-Teams, die direkt für die Kunden oder mit den Kunden zusammenarbeiten, also das Projekt Onboarding machen und Features entgegennehmen und so weiter. Und dann haben wir Plattform-Teams. Und eins der Plattform-Teams ist eins meiner Teams, das ist das DevOps-Team, für das ich verantwortlich bin. Ansonsten habe ich auch noch ein Application-Team. Das sind die zwei Teams, die ich manage. Du überlegst so, das passt sehr gut zusammen, weil das, was man onboardet, ist natürlich auch das, was man irgendwie macht. Ja, nein, elf hat man.

SPEAKER_02 5:57

Ich auch, weil ich überlege 100 Leute, dann finde ich zehn, elf Teams relativ viel. Die Entwicklungsteams, hast du die genannt. Das heißt, die haben schon alle irgendwie so. Elf Personen, oder? War das? Nee, nee, nee.

SPEAKER_00 6:09

Elf Teams. Wie gesagt, ich muss nochmal nachsehen, aber ich glaube.

SPEAKER_02 6:12

Aber grob. Und wenn die wie groß sind? Ungefähr?

SPEAKER_00 6:15

Ja, so alles zwischen drei und was ist denn das größte Team? Sechs.

SPEAKER_02 6:18

Ah, okay. Ja, dann sind wir okay. Das ist eigentlich schon die Größe, die man so anpaltet. Okay.

SPEAKER_00 6:22

Also wir haben schon den Großteil der Leute, arbeitet in der Entwicklung, eine Firma.

SPEAKER_02 6:27

Ja, gut, wenn es drei bis sechs ist, dann passt das auch. Dann sind ja irgendwie, roundabout, weiß nicht, 40 oder sowas, die nicht genau in diesen Teams arbeiten. Ich habe irgendwie gerade von größeren, habe dann an sechs, sieben Leute gedacht. Und dann wird es natürlich irgendwie schon knapp mit den anderen Rollen. Aber okay, cool. Okay.

SPEAKER_00 6:44

Und dann haben wir natürlich diese anderen Rollen, die man immer hat. Produktentwicklung, Projektmanagement, Architekten. Engineering Manager.

SPEAKER_03 6:52

HR.

SPEAKER_00 6:53

HR, natürlich, genau.

SPEAKER_03 6:55

Okay. Sehr gut. Vielleicht ein bisschen zum Kontext, warum wir auch bei Vodafone sind. Wir haben dich hier direkt von der Decompiled-Konferenz abgegriffen. Und da hast du einen Vortrag gehalten mit dem Titel There are no awards for being the busiest. Kannst du ein bisschen darauf eingehen, was du mit genau meinst?

SPEAKER_00 7:12

Gerne. Also meine Beobachtung ist, dass wir alle immer zu viel Arbeit haben. Immer, die ganze Zeit. Euch geht das mit Sicherheit auch so nahe. Es gibt immer so viele Sachen, die wirklich auf dem Tisch liegen und jetzt gemacht werden müssen. Und dann gibt es noch diesen Stapel an Sachen, die man gerne mal machen würde. Also diese ganzen Bücher, die man lesen würde oder diese Fähigkeiten, die man gerne erlernen würde. Und so geht das den meisten Teams auch. Also die sind meistens überschwemmt mit Sachen, die zu tun sind. Und die Frage ist, was macht man, um da rauszukommen? Und es gibt keine Methode, die dir hilft, das alles zu machen, aber es gibt eben Möglichkeiten, da irgendwie durchzuschneiden und die Dinge zu machen, auf die es ankommt. Dass man eben diese Awards bekommt. Es gibt natürlich keine echten Awards, aber es gibt gute Go-Lives, es gibt fertige Projekte, es gibt irgendwie andere Achievements mit dem Team, die man irgendwie erreichen kann. Und auf die kommt es an. Und da wollen wir hin.

SPEAKER_03 8:07

Und du hast gerade schon angesprochen, so es gibt natürlich nicht die Methode, aber es gibt natürlich eine Methode, die man nutzen kann, um das möglichst effizient zu gestalten. Ich glaube, eine Aussage von dir war auch so, Zeit ist das ultimative Asset, so das ist das, was am meisten wertgeschätzt wird. Und diese Zeit soll man möglichst am besten nutzen und dann am besten an den richtigen Dingen zu jeder Zeit zu arbeiten. Und da hast du eine Methode vorgestellt. Magst du ein bisschen darauf eingehen?

SPEAKER_00 8:33

Sehr gerne. Also das ist ein einfaches Modell, was ich benutze, um mit meinen Teams zu arbeiten. Die Idee ist, dass wir erstmal anfangen mit einer Pyramide. In der Pyramide sind vier Bausteine. Also ganz oben hat man die Mission, dann darunter kommen die Ziele, darunter die Roadmap und darunter der Backlog. So, und jetzt versuchen wir, da eine Kohärenz reinzubekommen. Weil oft hat man eben diese Sachen in irgendeiner Form mal mehr oder weniger gut organisiert. Aber wir versuchen das jetzt kohärent aufzubauen, indem man eben immer von oben anfängt. Man fängt immer mit der Mission an. Das ist das Warum. Warum bin ich da? Das ist meine Identität. Daraus kann ich meine Ziele feststellen. Also was ist dieser Award, den ich haben möchte? Und daraus leite ich meine Roadmap ab. Wie komme ich da hin und mein Backlog ist dann mein Daily Doing. Und die Idee ist, dass man das eben immer nacheinander ableitet. Voneinander ableitet.

SPEAKER_02 9:25

Du hast gerade gesagt, das ist dann für mich oder für eine Person, ist es eher so ein individuelles Ding oder ein Team-Ding?

SPEAKER_00 9:34

Wie du möchtest. Du kannst es für dich selber nehmen oder für dein Team oder für deine Firma, obwohl es da sehr schnell, also das hat dann recht viele Cross-Connections, die man so ein bisschen mit einplanen muss, aber im Prinzip kann man das in jedem Kontext nehmen. Also man staffelt ja auch gern die Ansicht von diesem Individuum-Team, Firma. Das geht so nach außen und du könntest es auf allen Ebenen benutzen, wenn du möchtest.

SPEAKER_02 9:55

Wie setzt ihr es konkret ein?

SPEAKER_00 9:57

Gerade eben benutze ich es vor allem mit meinen Teams. Wir versuchen das auch auf Firmaebene gerade umzusetzen oder wir setzen es gerade um, aber da wir da gerade noch so am Anfang sind, möchte ich da jetzt gar nicht so große Erfahrungswerte schon teilen. Das muss noch ein bisschen reifen und es braucht noch ein paar Iterationen, um da besser zu werden. Wir sind ja agil. Continuous Improvement.

SPEAKER_03 10:16

Achso, das ist etwas recht Frisches, dieses Konzept, was ihr einbaut?

SPEAKER_00 10:19

Meine Pyramide.

SPEAKER_03 10:20

Genau.

SPEAKER_00 10:21

Oder das Modell.

SPEAKER_03 10:22

Genau, genau.

SPEAKER_00 10:22

Ja, frisch. Also ich glaube, ich nehme das schon an sich eine Weile, aber dass ich es jetzt mal so ganz ordentlich aufgeschrieben habe, das habe ich jetzt gerade für die T-Com halt mal gemacht.

SPEAKER_03 10:31

Ach, okay, okay.

SPEAKER_00 10:32

Also gerade es gehören eben noch drei Regeln dazu, die man nutzen muss, um nicht nur an sich eine Kohärenz zwischen den Baustellen zu finden, sondern auch noch eine zeitliche Kohärenz zu finden. Weil diese Dinge ändern sich. Also mein Backlog ändert sich so oder so regelmäßig. Meine Ziele, meine Roadmap kann sich auch ändern, aber die Dinge ändern sich eben auch von außerhalb. Also ich habe immer externe Kräfte, die darauf einwirken, dass die Dinge nicht so laufen, wie ich sie geplant habe. Und das muss man noch mit einbauen, indem man eben sagt, dass es nicht nur so ist, dass die Dinge aufeinander aufbauen müssen, sondern ich muss auch regelmäßig reviewen, ob das alles passt. Und ich muss schauen, dass wenn eine Veränderung passiert in meinen vier Bausteinen, dass das entweder gecheckt wird, ob das mit der Ebene drüber noch passt, oder dass ich schaue, dass ich ein Review von meiner ganzen Pyramide mache. Also wenn sich die Situation komplett ändert und meine Ziele einfach nicht mehr passen, dann muss ich sie anpassen. Das ist die Idee dahinter. Und dass ich das jetzt mal so ordentlich aufgeschrieben habe und präsentabel gebracht habe, das war jetzt der Anlass hier.

SPEAKER_02 11:35

Ich habe eine Frage, Dave.

SPEAKER_03 11:37

Dann frag du zuerst. Ich wollte ein bisschen Struktur reinbringen.

SPEAKER_02 11:40

Ja, sorry. Aber nein, aber mach gern. Was wäre deine Frage gewesen? Die Frage, die du auch gestellt hättest: De ist, gibt es in der konkreten Implementierung irgendwie dann aber auch eine Vorgabe, wie und in welcher Frequenz man das evaluiert? Weil oft ist man, also ist es ein Tool, was ich mir irgendwie einmal, keine Ahnung, im Jahr angucke und irgendwie mich da alleine? Ist das was, was ich so täglich eigentlich nebeneinander schreibt stellen könnte, weil ich mich immer wieder reminden will, das ist eigentlich das, von wo ich komme und wo ich hin will. Oder was würdest du empfehlen, wie stark der Umgang mit diesem Tool ist?

SPEAKER_00 12:19

Also ich glaube, wenn man jetzt eine wirklich gute Mission und Ziele für sich gefunden hat, wäre das schön, wenn man die eingerahmt irgendwie im Büro hängen hätte. Es sollte nichts sein, was einen aber täglich beschäftigt. Also das ist was, man will ja auch den Mental Load irgendwie runterhalten von Teams und Menschen. Also es sollte was sein, was präsent ist und klar ist, aber es sollte einen nicht permanent beschäftigen. Also man setzt es einmal auf und dann gibt es erstmal Struktur. Gleichzeitig sollte man es aber nicht erst ein Jahr später angucken, weil da kann ich versprechen, dass man davon abgekommen ist. Da werden Sachen passieren, die mich vom Weg abbringen. Und das heißt, man muss sich vorher überlegen, was ist ein guter Cycle, das wieder anzugucken. Und das kann ich jetzt nicht sagen, was das für ein Team genau bedeutet, das muss man selber entscheiden. Ich finde, es gibt so natürliche Zyklen, in denen man das machen kann. Also wer Sprints macht, man guckt so oder so alle zwei Wochen in sein Backlog rein. Dann review ihn auch, schau, was der ordentlich passt. Ist das die Dynamik, die ich erwartet habe? Also ich weiß nicht, wie die Backlogs bei euch aussehen, aber die voll, genau.

SPEAKER_03 13:19

Die cool doch gar nicht mehr. AI ist doch da. Ah ja, stimmt. Die macht das einfach. Die AI arbeitet alles ab.

SPEAKER_00 13:25

Aber so ein voller Backlog ist nicht gut. Also ein Backlog soll nicht voll sein, der soll gut strukturiert sein und da sollen ausgewählt Sachen drin sein, die wir wirklich jetzt demnächst angehen wollen. Und so ein Review, das, ob das jetzt alle zwei Wochen immer klappt, aber man sollte es sich vornehmen. So eine Roadmap, wenn man jetzt ein stabiles Team hat, was jetzt nicht in einem engen Projekt ist, das sollte schon alle drei Monate irgendwie nochmal angeschaut werden, passt es noch? Haben sich da fundamental Sachen geändert. Bei Zielen, ja, ich würde sagen, alle halbe Jahre sollte man mindestens mal drauf schauen, passt es noch? Spiegelt es noch, die Situation wirklich wider? Und so eine Mission von dem Team sollte sich jetzt nicht ständig ändern. Das wäre nicht gut. Das ist dann so eine Red Flag, ist, glaube ich, was anderes im Argen. Aber so einmal im Jahr würde ich schon raten, dass man sich als Team Zeit nimmt und sich das wirklich mal anschaut. Und das braucht wirklich Zeit. Das ist nicht in einer Stunde mal so zwischendurch gemacht. Man braucht Raum, man braucht Inspiration, man braucht auch Reflexionsmöglichkeiten darüber. Man kann nicht aber sagen, lies mal die Mission und sag mir bitte, ob das jetzt noch stimmt.

SPEAKER_03 14:27

Ich finde das ja interessant. Ich kann ja auch ein bisschen aus dem Nähkästchen plaudern, weil ich ja auch Produktverantwortlicher bin bei uns. Und je nachdem, wann sie rauskommt, ist vielleicht wahr. Es hat keine Lust mehr auf mich. Nein. Thema für eine andere Folge. Genau. Und ich gerade auch gemerkt habe, ich erkenne da viele Parallelen. Also ich glaube, bei uns ist es oft so diese Quartalsstruktur, wo wir dann zumindest hinterfragen, haben sich unsere Ziele geändert? Wenn nicht, übernehmen wir sie weiter. So, unsere Mission, beziehungsweise wir nennen sie Vision, ist relativ stabil. Aber ich merke halt trotzdem immer wieder in der Kommunikation mit meinen Devs, dass diese Unterscheidung zwischen Mission und Zielen gar nicht so einfach darzulingen ist. Wie würdest du diese Sachen unterscheiden, diese beiden Aspekte, Mission und Ziele?

SPEAKER_00 15:12

Ja, es wird auch schnell vermischt und es ist auch, ich glaube, beide Konstrukte sind halt irgendwie sehr abstrakt. Also was ist eine Mission oder Vision? Also was heißt Identität? Das ist ja auch was nicht einfach Greifbares. Und auch Ziele, das ist eben, das geht so in die Zukunft rein, das heißt, es geht auch so in dieses Abstrakte, deswegen vermischt man das gern. Ich nehme dazu immer gern das Beispiel von, wenn man jetzt mal so ein Hobbybeispiel nimmt für sich selbst. Wenn ich jetzt sage, ich bin jetzt sehr ambitioniert sportlich, ich möchte was erreichen. Das heißt, ich sage jetzt, ich möchte jetzt mal meinen ersten Marathon laufen. Mal einen richtigen Award bekommen. Das ist ein Ziel. Das ist dieser Award, den ich haben möchte. Meine Mission dahinter ist eine andere. Das hängt jetzt davon ab, aus welchen Gründen man jetzt diesen Marathon laufen möchte, aber wenn ich jetzt sage, ich möchte einfach eine richtig gute Midlife-Chris, danke. Also ist meine Mission, mit meiner Midlife-Crisis umzugehen. Oder ist meine Mission, ich möchte einfach eine richtig gute Langstreckenläuferin sein. Also was ist meine Mission dahinter? Und das eine ist langlebiger als das andere. Also ich bin immer noch eine gute Langstreckenläuferin, wenn ich diesen Marathon gelaufen bin. Dann kann ich mir ein neues Ziel setzen. Meinen zweiten laufen oder ne? Während diese Ziele sollten erreichbar sein und sollten auch was sein, was, ja, nee, doch, was man erreicht. Ich muss irgendwie eine Definition of Done für mein Ziel haben.

SPEAKER_03 16:39

Und eine Sache, über die du also davor gesprochen hast, ist so ein bisschen, gerade was Mission und Ziele angeht, man sollte mal ordentlich hinsetzen. Also ich habe so leicht rausgehört, das ist oft wahrscheinlich ein Aspekt, der sehr stark vernachlässigt wird. Echte Frustration. Genau, genau. Also Leute, macht es mal richtig. Gibt es da irgendwie was konkret, was du da empfehlen könntest? So ist es irgendwie gut, wenn man sich als Team mal wirklich zusammensetzt, eine Offside geht, komplett aus dem Office raus, da wirklich dann zwei, drei Tage am Stück überlegt, so, hey, wer sind wir, was macht uns aus, wo wollen wir hin? Oder hast du da irgendwelche handfesten Tipps?

SPEAKER_00 17:07

Ja, also auf jeden Fall eine Woche Mallorca, Finka. Gar nicht mal so direkt.

SPEAKER_01 17:14

Ja, sehr gut.

SPEAKER_00 17:16

Also ich finde schon, wenn man die Möglichkeit hat, sich ein, zwei Tage zu blocken als Team und sich da mal wirklich mit zu beschäftigen, gerade wenn man das zum ersten Mal macht, ist es das wert. Also man kommt da auch gut durch, man findet eine Mission und Ziele und vielleicht sogar schon erste Ideen für die Roadmap. Aber es ist natürlich viel Zeit und das überspringt man gern, weil zwei ganze Tage für ein Team oft sehr viel sind, gerade wenn man in so Projektteams oder sowas sitzt, da ist die Zeit so eng und die Deadlines auch so eng, dass man das ungern hergibt. Aber einen Tag würde ich auf jeden Fall empfehlen, dass man sich das nimmt. Und man muss es auch gut vorbereiten. Tipps, wie man das macht, ist schwierig, weil wenn man so im Internet schaut, was gibt es denn so an Material zum Thema Mission und Ziele finden, dann sieht man, es gibt Unmengen an Literatur, die man lesen könnte. Es gibt auch Unmengen an Formaten, die man nutzen könnte. Ich finde es wichtig, dass man versucht, die richtigen Fragen zu finden, um das aus dem Team herauszubekommen. Also die Missionen und die Ziele, die stecken schon in dem Team drin. Man muss das nur herausdestillieren. Wenn man das nicht schafft, dann ist es auch wieder so eine Red Flag, dass da irgendwas nicht stimmt. Also es kann sein, dass das Team da nicht stimmt. So, aber wenn das Team stimmt, dann kriegt man das da raus.

SPEAKER_03 18:28

Oder das Alignment, dass da nicht stimmt. Man hat unterschiedliche Vorstellungen irgendwie, wo man eigentlich hin möchte.

SPEAKER_00 18:32

Genau, ja, das kann auch sein, dass es dann, aber dann ist es vielleicht auch ein Missmatch von Leuten, die in diesem Team sind. Also wenn man das nicht auf eine Bahn gelenkt bekommt, also da stimmt auf jeden Fall was anderes nicht. Das ist meine Erfahrung, sage ich mal.

SPEAKER_02 18:47

Und wie viel spielt da eine strategische Komponente von außen dann eine Rolle? Also es gibt ja wahrscheinlich irgendeine Hierarchie in der Regel und du hast jetzt gesagt, okay, dann sollte aber trotzdem irgendwie das Team auf die Mission auch kommen. Die ist ja aber, das Team ist ja trotzdem irgendwo vermutlich geleitet durch irgendwelche Rahmenbedingungen, die sie jetzt nicht selbst im Team entwickeln. Wie spielt das da rein? Also an welcher Stelle ist das der Input sozusagen.

SPEAKER_00 19:16

Genau, ein Team sollte nie losgelöst von der Organisation existieren. Genau, also es darf jetzt nicht, man kann sich jetzt nicht irgendwas ausdenken. Gut, man kann das vorgeben, man kann Input geben, das geht. Jetzt komme ich aus der anderen Richtung. Ich glaube daran, dass man tatsächlich selbst organisierte Teams schaffen kann. Die schaffen sich nicht von selbst, aber man kann das schaffen. Und wenn man tatsächlich selbst organisierte Teams hat, hat man eine sogenannte Selbstemergenz. Heißt das so auf Deutsch? Emergenz.

SPEAKER_03 19:44

Ich finde es sehr schön. Wird Linken nennen das so.

SPEAKER_00 19:47

Also das heißt, dass diese Dinge, wenn die Mission der Firma verstanden ist und die Ziele verstanden sind, die Teams durchaus in der Lage sind, das auch aus sich selbst heraus zu generieren, dass es passt. Also das ist die Idee von tatsächlicher Selbstorganisation. Dass man es eben nicht immer injizieren muss.

SPEAKER_03 20:05

Und würde das Unternehmen das gleiche Modell nutzen?

SPEAKER_00 20:08

Man kann das auch nutzen, ja.

SPEAKER_03 20:10

War auch mein erster Gedanke. Also theoretisch könnte das Unternehmen ja eine Mission haben, Ziele haben und daraus leiten sich wieder Missionen und Ziele für die jeweiligen Unterteams ab.

SPEAKER_00 20:17

Genau, man kann das dann verlinken. Wenn man das auf Unternehmensebene macht, hat man, genau, wie man sagt, Missionen, Ziele, man hat Unterziele, das ist so diese Roadmap-Ebene. Die Backlog-Ebene wird dann meistens recht dünn, weil man selten tatsächliche Work-Packages so auf Organisationsebene hat, aber es gibt es schon auch. Und die Idee ist, dass wenn man dann eben diese Pyramide auf Organisationsebene hat, man das verlinken kann. Also man schafft dann sozusagen Alignment. Gutes Wort. Also ich frage jetzt immer, möchte ich Alignment oder Kohärenz? Also was möchte ich, aber in dem Moment kriege ich Alignment. Dass ich eben, wenn ich alle Teampyramiden habe, die alle auf dieselbe obere Pyramide verweisen, müsste ich theoretisch Alignment bekommen.

SPEAKER_03 20:59

Ah, okay. Ja. Das heißt, so würdest du auch Alignment und Kohärenz unterscheiden?

SPEAKER_00 21:02

Genau, also Kohärenz ist was, wie heißt es, Verteiltes. Also das sind Sachen verteilt und es kommt aus sich selbst heraus. Vielleicht geht es auch einher. Ich habe es, ja, also ich könnte ja mal was dazu sagen.

SPEAKER_03 21:13

Philosophieren. Da wir noch aktuell bei Mission und Zielen sind, also im oberen Teil der Pyramide, was würdest du aber bei den beiden Sachen schon sagen, was ist so der größte Vorteil, sich darüber im Vorfeld Gedanken zu machen? Also inwiefern wirkte sich das positiv auf den Rest der Pyramide aus?

SPEAKER_00 21:29

Die Pyramide ist deswegen eine Pyramide und kein Trapez, weil das oben hin spitz wird. Und das wird spitz, weil da der Fokus und die Klarheit von Mission und Zielen, wie ich meine Erfahrung, konvergiert. Das muss dahin konvergieren, ja. Also die Mission muss sehr scharf sein. Die Ziele auch, also es sollten auch nicht so viele Ziele sein. Also wer sich fünf, sechs Ziele nimmt, hat sich zu viel vorgenommen. Das wird man nicht schaffen. So, weil das sind eben diese engen Teile in dieser Pyramide. Und das Ding ist, wenn ich das jetzt zu breit. Mache, dann wird der untere Teil meiner Pyramide auch breiter und verdünnt dann sozusagen immer mehr. Das heißt, mein Fundament wird immer dünner und brüchiger. Und das Fundament muss stabil sein, damit es den Rest der Pyramide tragen kann. Ich habe das Gefühl, ich werde immer abstrakter.

SPEAKER_02 22:18

Genau, ich mag es eigentlich jetzt gerne, weil es ja irgendwo diese in beide Richtungen geht. Also, das eine gesagt, eigentlich startet man ja irgendwo oben, um das zu definieren. Und andererseits finde ich das Bild eigentlich ganz schön, okay, wenn du dann unten rauskommst und da irgendwo dann zu viel hast, dass das andere dann wiederum auch nicht tragen kann, wo es dann auch wieder nach oben babbelt und dass es irgendwie gegenseitig stützen muss. Finde ich natürlich eigentlich ganz gut.

SPEAKER_03 22:41

Mir ist so, wenn so ein anderes Bild in den Kopf gekommen, weil du gerade Trapez gesagt hast und ich mir ein bisschen vorstellen musste, so wie. Was ist ein Trapez? Echt? Der schockierte Blick gerade, was kann man nicht sehen? Zum Glück machen wir heute ohne Video. Den Shade, den ich geworfen habe. Weil ich mir eigentlich vorgestellt habe, wie diese Pyramide quasi in einem Quader oder in einem, also ein Quader an unendlichen Möglichkeiten drin ist. Schreibt mal ganz kurz ein Quader. Sorry, Quaders ist die falsche, ich meinte eigentlich ein Rechteck, einfach nur Quaders ein Körper und wir reden über Flächen zweidimensionalen.

SPEAKER_00 23:14

Es ist es aber auch zweidimensionalen, dass es eingebettet ist.

SPEAKER_03 23:16

Oh Gott, okay. Nein, wir bleiben im 2D, das kann man gerade noch so irgendwie ab. Genau, wenn man dieses Quader an unendlichen Möglichkeiten hat und dann die Pyramide. Entschuldigung, scheiße, es ist wieder Quader. Ja, es muss mal weiter Rechteck. Genau, das Rechteck hat. Eigentlich sind wir dann, okay, wir reden viel zu viel über irgendwelche Körper. Das ist auch ein Kreis. Das ist auch ein Kreis. Nee, und dann quasi diese unendlichen Möglichkeiten nach links und rechts hat, dann so eine Pyramide sagt ja auch so aktiv so, hey, wir sagen dazu nein. Wir sagen dazu nein, was links ist, wir sagen dazu nein, was rechts ist, so, sondern das ist wirklich jetzt unsere Mission, daraus leiten sich diese Ziele genau ab und darauf können wir arbeiten. Weil sonst sagt man wieder zu vielen Dingen ja und ich glaube, dieses ein, das Problem, das wir eingangs hatten, was du meintest, das Backlog ist riesig, einfach aufgrund von Dingen, wo man gesagt hat, so, ja, sagen wir dazu jetzt ja oder nein? Und ich glaube, das ist hoffentlich ein schönes Bild. Ich fände es super schön, ja.

SPEAKER_00 24:06

Es gefällt mir sehr gut, ja. Weil dieses eine gute Mission und Ziele finden, heißt auch sehr viel Nein sagen. Es ist nicht nur schwer, die richtigen Fragen zu stellen, sondern es ist auch oft schwer, wirklich Nein zu sagen. Es sind harte Entscheidungen, die man trifft. Es gibt oft Sachen, wo man sagt, das ist jetzt aber auch wirklich wichtig, aber es geht halt nicht.

SPEAKER_02 24:23

Und deine Hypothese oder beziehungsweise vielleicht auch Erfahrung ist, dass wenn das einmal besprochen ist, dass das im Alltag erleichtert, dass man eben nicht die ganzen Sachen hat, die man auch parallel machen möchte.

SPEAKER_00 24:35

Genau, im Idealfall ist das so. Also wir haben begrenzt Platz in unserem Kopf. Ich glaube, irgendwie acht Dinge kann man gleichzeitig im Kopf haben.

SPEAKER_03 24:44

Ich glaube, ich glaube, sieben Dave mehr. Ah, ja, ja, genau. Sieben ist so eine magische Zeit bei Menschen, habe ich gefühlt. Es gibt die sieben Weltmeere, obwohl es ja potenziell mehr Meere gibt. Es gibt die sieben Weltwunder, obwohl hier allein schon drei Weltwunder sitzen. Also genau, deswegen, es könnte ja wirklich mehr geben. Also sieben ist, glaube ich, so eine magische Zahl.

SPEAKER_00 25:00

Ja, okay, lass sieben sein, also Größenordnung, stimmt. Also es ist eben sehr begrenzt, was wir im Kopf haben können. Und wenn wir eben diese ganzen Sachen die ganze Zeit auch im Kopf haben, was jetzt zu tun ist, nehmen wir uns selber die Möglichkeit, diese Sachen wirklich abzuarbeiten. Weil wir müssen diesen Mental Load irgendwie losbekommen, um leistungsfähig zu sein. So, und indem ich mich hinsetze und das aufschreibe und auch als Team mich darauf verständige, dass wir das jetzt so machen, dann habe ich erstmal Platz geschaffen für die anderen Sachen. Und natürlich muss ich mich im Alltag immer mal wieder damit beschäftigen, wie ich schon gesagt habe, man muss es immer wieder checken, passt es immer noch und so weiter, aber ich muss es halt nicht jeden Tag machen. Und ich kann dann auch einfach mal an Tagen sagen, wir haben es besprochen, ich weiß, was jetzt zu tun ist. So, ich kann mich jetzt auf den nächsten Schritt konzentrieren und nicht immer auf alles andere, was auch noch danach kommen müsste.

SPEAKER_03 25:49

Ich glaube, also ich glaube, das hilft dem Team insgesamt halt einfach super gut zu sagen, wenn irgendwie Output von außen kommt, so von wegen, hey, ihr könnt doch mal schnell doch das einbauen oder so, und dann kann man damit argumentieren, nee, unsere Ziele sind eigentlich so und so. Das zahlt gar nicht drauf ein. Warum sollten wir das priorisieren an der Stelle?

SPEAKER_00 26:02

Genau.

SPEAKER_03 26:02

Also eigentlich eine gute Maßnahme.

SPEAKER_00 26:03

Es ist ein gutes Kommunikationsmittel. Ich kann damit einfach auch nach außen gehen und sagen, das ist das, worauf wir uns verständigt haben. Und darauf berufe ich mich. So, und wenn sich Dinge so ändern, dass es eben nicht anders geht, dann muss man es eben wieder neu verhandeln, das ist okay. Aber ich habe immer die Möglichkeit, damit erstmal Grenzen zu ziehen. Und meine Erfahrung ist auch, dass die Leute, die gut zu den Grenzen ziehen und Nein sagen, das sind die Leute, die man auch gerne als sogenannte High-Performer bezeichnet. Also das sind, es sind nicht die, die immer zu einem Ja sagen und alles wegarbeiten, es sind die, die wirklich klare Grenzen haben und sich auch einen Prozess erhalten. So, eine Beobachtung.

SPEAKER_03 26:37

Spannender Take.

SPEAKER_00 26:39

Es sind Leute, die auch auf ihre Ressourcen achten. Könnt ihr auch nochmal überlegen. Also es gibt sicherlich auch Leute, die High-Performer sind und die ganze Zeit super für arbeiten.

SPEAKER_02 26:50

Dann ist es gerade ein bisschen überfordert mit dem Überleben. Finde ich super spannend, aber deswegen haben wir beide auch, glaube ich, gezögert, weil man erstmal dann natürlich darüber nachdenken muss. Und erstens, in welchem Setting ist, was man kennt, man versucht da ein bisschen drauf zu reflektieren. Deswegen ist gerade die Antwort nicht so schnell gekommen. Aber ja, es ist spannend. Spannendes Ding.

SPEAKER_03 27:10

Ich glaube, ja, weil ich auch spontan an Leute gedacht habe, wo ich sagen würde, das ist ein High-Performer, aber ich glaube, die rattern auch sehr viel weg in der Breite. Also, das ist, glaube ich, auch das Interessante. Und ich glaube, bei dem Case, den du gerade genannt hast, also ich würde das nicht per se ablehnen, aber ich glaube, da müsste ich nochmal trotzdem überlegen, weil ich glaube, ich glaube, es ist vielleicht so ein Mindset, das generell ein bisschen in uns verankert ist, so irgendwie, ja, wenn man viel macht, dann ist gut, aber es ist ja, also wenn du viel machst, was nutzlos ist, also warum sollte es dann besser sein? Also, eigentlich spannender Gedanke. Exakt.

SPEAKER_00 27:40

Also ich sage das vor allem, es gibt mit Sicherheit auch Leute, die super viel arbeiten und auch sehr, sehr gut Leistungen da abliefern. Aber ich würde es vor allem sagen, dass man nicht immer das Gefühl hat, wenn ich jetzt Nein zu etwas sage, dann wird sich das negativ auf meine Leistungsbeurteilung auswirken. Also, das ist nicht die Erfahrung, die ich gemacht habe. Es sind andere Sachen, die sich negativ darauf auswirken.

SPEAKER_03 28:04

Du saßt so grübelnd aus.

SPEAKER_02 28:07

Ja, also warum ich grübel, haben wir ja gerade schon geklärt. Ich kann eine Frage stellen. Soll ich eine Frage stellen? Oder du hast du gerade. Du guckst sehr konzentriert heute in dein Handy die ganze Zeit.

SPEAKER_03 28:16

Ich habe hier mega viele Notizen. Ich nehme diese Aufgabe sehr ernst, quasi das zu moderieren. Aber den Faden reinbringen. Und du bringst niemals aus diesen Faden raus, was vollkommen okay ist, eben so ist unser Podcast.

SPEAKER_02 28:25

Aber das ist auch eine Gefahr, so eine Struktur zu haben.

SPEAKER_03 28:28

Dann denkst du, oh, jetzt müssen wir darüber reden. Nee, ich will es ja immer nur in die gerade Bahn lenken. Ich habe es schon sehr oft ausbrechen lassen. Okay, soll ich ausbrechen? Brech mal kurz aus, komm.

SPEAKER_02 28:38

Einer hat. Wie siehst du, also es gibt ja durchaus auch andere Systeme. Nein, machen wir nicht. Die versuchen darauf einzugehen, so ein bisschen eine Organisation zu strukturieren. Ich glaube, eins der ganz Großen ist irgendwie, was Google mal gemacht hat mit OKRs, was ja irgendwie Objective und Key Results sind, was aber auch so ein bisschen, es bubbelt von oben ein bisschen was runter und von der anderen Seite es bubbelt von unten ein bisschen was hoch und jeder hat so seine definiert ein bisschen klarer, was sind denn eigentlich unsere Ziele auch und da noch stärker vielleicht auch, wie können wir sie messen. Ich glaube, das ist nicht unbedingt jetzt in dem Modell. Haben wir den Namen für dieses Modell schon genannt?

SPEAKER_00 29:18

Das ist das VTA-Model, das Vision to Act Model.

SPEAKER_02 29:21

Vision to Act, ja. Gut, okay, aber gut, gut moderiert, denn das ist ja. Danke. Wie siehst du da die Abgrenzung? Siehst du das überhaupt als konkurrierende Dinge? Also hast du das Gefühl, das sind einfach Ansätze, mit denen man diese Probleme lösen kann oder sagst du, das ist eigentlich was noch anderes?

SPEAKER_00 29:43

Es ist nicht konkurrierend. Ich kann beides gleichzeitig machen, wenn ich das denn möchte. Weil mein Modell sagt nicht, wie du diese Mission findest oder diese Ziele findest oder wie du das genau ausgestaltest. Du könntest OKR dafür nehmen, wenn du möchtest. Aber meine Meinung generell dazu ist, dass man immer schauen sollte, was wirklich zum eigenen Team passt oder zum eigenen Setting passt. Ich würde, glaube ich, immer davon abraten, einfach irgendein Framework zu nehmen und das umzusetzen. Das mag zufällig passen, aber ich glaube, in den meisten Fällen schafft das auch immer viel Reibung. Also es ist ja irgendwie immer, ich nehme eine Schablone für irgendwas und lege das über was drüber und hoffe, dass dann irgendwie die Menschen da reinpassen. So, und deswegen würde ich immer dazu raten, sich genau anzuschauen, was machen diese Frameworks, was macht die aus und was brauche ich davon wirklich. Also generell jetzt von OKR abgesehen, würde ich das zu jedem Framework sagen. Und ich glaube, der Trend geht auch so in dieser ganzen agilen Organisationsentwicklung, geht auch mehr dazu, dass man eben nicht mehr zu diesen fertigen Frameworks zyniert, sondern dass man wirklich sagt, schaut, dass ihr euch das Maß schneidet. Dafür gibt es ja auch Leute wie mich, die in Firmen arbeiten, die das machen.

SPEAKER_03 30:53

Ja, also allein von der Definition hätte ich ein bisschen gesagt, dass das sehr gut sogar synergieren kann. Also ich finde dieses Vision-to-Act-Modell, was du ja mit der Pyramide meinst, worauf wir gleich nochmal näher eingehen werden. Wir haben ein paar Ebenen ausgelassen. Aber dass wir quasi bei OKR, was ja Objectives-Key-Results sind, ich glaube, da ist es eher so ein bisschen, man kann die Ziele da rausnehmen aus der Pyramide und dann schauen, wie machen wir die messbar. Also ich, also in meinem Verständnis von beiden Systemen ist es so, man kann das eigentlich sehr gut kombinieren.

SPEAKER_00 31:21

Wenn man diese Messbarkeit möchte.

SPEAKER_03 31:23

Genau, wenn man sie möchte, genau, wenn sie relevant.

SPEAKER_00 31:24

Ich kann nicht fragen, ob man das unbedingt braucht. Also wir tendieren ja so immer alles so messbar zu machen. Also man möchte immer so Daten erheben und alles haben. Aber am Ende, also der ganze Trend geht ja jetzt auch so Richtung in diese sozio-technologischen Aspekte von Softwareentwicklung, muss man sich auch fragen, wie gut kann ich Sachen messen, wenn ich mit Menschen arbeite? Also muss ich alles messen können? Das ist immer notwendig. Deswegen meinte ich auch zu einem Ziel, also man kann Smart Goes machen, also sehr messbare Ziele machen. Oder man hat eher so, ich habe es Directional Priorities genannt, also gibt es eher eine Richtung vor, aber dann brauche ich irgendwie ein gemeinsames Verständnis von der Definition of Done. Also wann können wir sagen, dieses Ziel ist jetzt erreicht? Oder wir können ein weiteres Ziel daraus machen, ja. Die Frage kann man sich immer stellen.

SPEAKER_03 32:08

Ja. Oh, finde ich interessant, weil wenn man jetzt auf das Produkt achtet, würde ich sagen, braucht man ja schon eine gewisse Messbarkeit, um Erfolg festzulegen. Also beispielsweise, keine Ahnung, bei einem Produkt ist einfach, man verkauft es, dann will man ja sagen, wir wollen es häufiger verkaufen. Und wenn Leute irgendwie ein Abo haben, dass die Leute länger bleiben oder mehr Leute ein Abo abschließen über längere Zeit. Also finde ich, ist dann, glaube ich, da eine Messbarkeit schon durchaus relevant. Und deswegen, aber du hast ja dieses Soziologische irgendwie. Soziotechnologisch. Kannst du darauf noch näher eingehen, weil das würde ich interessant finden, also was man da irgendwie, worauf man da achtet?

SPEAKER_00 32:42

Also im Prinzip geht es da, das ist allgemein beschreibt es eine Richtung, in die man sich so überlegen kann, wie die Sachen aussehen. Und mein Gefühl ist, dass gerade mit diesem AI in der Nutzung zur Entwicklung von Software das aufgekommen ist, dass man sich wirklich fragt, was ist denn jetzt der Teil, den die AI macht und was ist der menschliche Teil? Also dass man sich dadurch erst so richtig überlegt, was macht der Mensch eigentlich in dieser Entwicklung, weil vorher wurde eben Software von Menschen entwickelt. Und dadurch ist diese Abgrenzung überhaupt zu suchen. Genau, und da gibt es natürlich verschiedenste Themen, mit denen man sich da beschäftigen kann. Also arbeiten wir mit AI oder die AI mit uns oder solche Sachen. Aber die Frage ist zum Beispiel jetzt auch in dem Fall, wenn ich Ziele mache, die messbar sind, was jetzt bei so einem Produkt irgendwie Sinn ergibt, ich möchte wissen, wie viele Abonnenten ich habe, ist es gut. Wenn ich jetzt aber Ziele habe, die messbar sind, die sich wirklich eher auf das Team beziehen, dann ist es eben nicht an einem Produkt gemessen, sondern an Menschen gemessen und das macht was mit Menschen. Und die Frage ist immer, macht es das mit Menschen, was es soll, oder macht es was anderes? Hast du es unter Kontrolle? Und wie viel können wir noch auf unser Bauchgefühl hören, wenn wir eigentlich noch Daten angucken? Also ich bin nicht gegen das Messen, das möchte ich damit nicht sagen, aber ich meine nur, es muss nicht immer alles messbar sein.

SPEAKER_03 33:59

Das ist spannend, weil ich also aus einer sehr datengetriebenen Rolle herauskomme und alles ist auch immer so. Ich lasse nicht ausreden. Ja, genau. Das ist durchaus ein Aspekt bei uns, also weil wir ja auch Spiele machen und dann auf der einen Seite so haben wir ja einfach so diese harten Fakten, so das sagen die Zahlen, das ist so das, was wir quantifiziert haben. Und gleichzeitig gibt es ja auch qualitatives Feedback. Leute schreiben uns, Leute äußern ihren Frust. Und da sind natürlich immer diese Gegensätze, so, hey, das Produkt performt rein zahlentechnisch richtig gut. Wir kriegen aber jetzt gerade irgendwie 500 Nachrichten von Leuten, die das komplett hassen. Aber eigentlich funktioniert das auch nicht. Die teilen die Liebe mit uns. Sie teilen die Liebe mit uns.

SPEAKER_00 34:33

Hard love.

SPEAKER_03 34:34

Und das ist aber auch schon ein interessanter Aspekt. Darauf hört man.

SPEAKER_00 34:38

Genau, das ist auch so ein Teil von diesem soziotechnologischen Aspekt. Wenn Menschen mitarbeiten, haben sie Emotionen, aber viele der Frameworks, die wir benutzen, legen überhaupt keinen Wert auf diese Emotionen. So. Und das kann ich dann eben nicht abbilden. Also dieser alles, was ich messe, sind ja irgendwie Abbildungen von was sehr Abstrakten, vierdimensionalen auf irgendwas, eine Zahl, ein D. Das ist eine krasse Abbildung. Du lässt super viel weg, indem du das machst.

SPEAKER_02 35:02

Und wo ich dir noch kurz nicht widersprechen, aber ergänzen möchte letztendlich, was wir ja gar nicht messen, ist ja irgendwo dann doch die Produktivität oder die Effizienz oder sowas. Was ja da irgendwie, glaube ich, auch nicht. Au menschlicher Ebene machen wir das nicht. Ein sehr wichtiger Teil ist, um den es jetzt auch gerade ging, so wie was macht das dann mit den Menschen und keine Ahnung was, weil das haben wir ja zum Beispiel gar nicht. Also es gibt, wir haben keinen Auftraggeber, wir haben nur irgendwie uns selbst. Das heißt, es ist so ein sehr freier Raum, in dem man irgendwie agiert, wo man sich natürlich auch manchmal fragt, okay, so ein bisschen wäre irgendwie ja ganz schön zu wissen, wenn du irgendwelche Entscheidungen triffst, wie du was strukturierst und wie irgendwie das zu wissen. Und es basiert halt aktuell komplett, würde ich sagen, auf dem Bauchgefühl. Um zu sagen, wie läuft die Entwicklung bei uns.

SPEAKER_03 35:49

Und gefühlt auch, das funktioniert in einem Team gut, in dem anderen auch. Ja, okay, dann muss es für alle Teams gleich gut funktionieren. Und jedes Team hat wahrscheinlich andere Ansprüche, aber wir machen das vielleicht gerade nicht so individuell. Ja, das ist ein anderer Podcast, aber finde ich auch ganz gut, dass es so ist.

SPEAKER_00 36:03

Ich meine, also dafür gibt es auch eben so Ansätze, dass man sagt, ah ja, diese Dev-Ex-Geschichte, da muss man eben Umfragen machen, dass man da irgendwie messbare Skalen kriegt und so weiter, dass man irgendwie Verbesserungen feststellen kann. Also es ist auch doof, wenn man gar nichts misst, weil man dann, ja, wie gut ist dein Bauchgefühl?

SPEAKER_02 36:19

Meinst du ganz gut?

SPEAKER_00 36:20

Ja, super!

SPEAKER_03 36:22

Selbstbewusst. Gut. Ich würde an der Stelle aber nochmal wieder auf die Ebene eingehen. Auf die Ebene eingehen. Genau, ganz genau.

SPEAKER_02 36:29

Wir haben das schon gefühlt, dass du gerne noch die dritte Ebene erstmal klären möchtest.

SPEAKER_03 36:33

Ja, vielleicht soll man auch die vierte, mal gucken. Wir haben über die VTA Vision to Egg-Pyramide geredet. Zwischenfrage. Ist das.

SPEAKER_02 36:44

Ist das ein Wording von dir, ja, oder? Okay, also das ist nicht, weil was soll das sein, sondern.

SPEAKER_00 36:48

Nee, ich muss es vielleicht auch mal irgendwo veröffentlichen auf irgendeinem Blog.

SPEAKER_02 36:50

Ich wollte gerade sagen, damit wir das jetzt, damit das ein Ding wird.

SPEAKER_00 36:54

Ja, ich habe meinen Auftrag verstärkt.

SPEAKER_03 36:57

Interessant, weil genau, das wird nur mit dir assoziiert, so sonst generell gut vor. Ja, genau, deswegen. Sehr gut. Wir haben über die Missionen und Ziele geredet, was das bringt und es oft hilft, Nein zu sagen. Da gibt es jetzt aber die dritte Ebene. Das ist die Roadmap. Da ist vielleicht wichtig, wenn man jetzt sagt, hey, okay, wir lassen uns auf die Roadmap ein, was ist wichtig, wenn man diese erstellt und worauf sollte man da unbedingt achten?

SPEAKER_00 37:22

Das kannst du mir wahrscheinlich sogar noch besser sagen.

SPEAKER_03 37:24

Aber ich bin ganz kurz verwirrt, warte mal. Mission, Ziele, Roadmap. Und dann? Dann ist das Backlog, die letzte Stufe.

SPEAKER_00 37:33

All das, was wir besprechen, müssen wir wirklich machen. Das ist wichtig. Gut. Okay.

SPEAKER_02 37:38

Genau, weiter.

SPEAKER_00 37:40

Die Roadmap, oh Gott, das ist so awesome. Für mich ist die Roadmap, also es ist natürlich der Weg, wie wir da hinkommen. Also wir brauchen irgendwie die Bausteine, um was aufzubauen, um diese Ziele zu erreichen. Das heißt, wir müssen identifizieren, was braucht es. Was eine Roadmap für mich auch ist, ist ein starkes Kommunikationsmittel, weil diese Bausteine zu finden, das mag das eine sein, sie aber zu priorisieren auf einem Zeitstrahl, ist nochmal was anderes. Also man muss irgendwie in Interaktionen mit anderen Menschen treten, in der Firma, Stakeholdern, weiß nicht, hängt vom Team ab. Also das ist das eine. Und was ich auch immer empfehlen würde, ist, sich genau zu überlegen, wie diese Roadmap eigentlich aussieht. Ich glaube, man ist immer sehr schnell daran zu sagen, ja, Zeitstrahl und jetzt kommen da irgendwelche Lanes, irgendwelche Sachen, die wir da machen. So bin ich. Ja, ja, also es ist ja auch, man hat dann, aber dann hat man wieder diese Divergenz so schnell, dass man irgendwie sagt, oh ja, dann packe ich das alles da rein und es wird irgendwie abgearbeitet, aber man muss sich genau überlegen, welche Kapazitäten habe ich eigentlich. Also ich habe eine bestimmte Zeit, die ich arbeiten kann und die muss ich einteilen in bestimmte Fragmente, die irgendwie da sind. Also wenn ich jetzt wie in meinem Fall mit einem DevOps-Team arbeite, die müssen eben bestimmte Zeit allokieren, um Support machen zu können. Wenn wir ein Incident haben, wenn irgendeine Pipeline down ist, müssen die wie die Feuerwehr einspringen und das irgendwie hinbekommen. Da können die nicht bis oben hin ausgeplant sein, wir müssen da irgendwie Zeit für haben. Und das muss man vorher mit reindesignen. Also welch, wie viel Zeit brauche ich für was? Weil das bedeutet, auch für deinen Backlog wird das eben Raum einnehmen. Du kannst ja nicht mehr so viel in dein Backlog reinschieben, weil du ja Zeit für andere Sachen frechlassen musst.

SPEAKER_03 39:21

Ah, okay. Das heißt, also nur um das richtig zu verstehen, das heißt, du würdest auch einordnen, auf der vertikalen hast du quasi diese maximale zeitliche Auslassung, die wir haben können. Und auf der Horizontale halt quasi, was wann kommt. So wird es das strukturieren.

SPEAKER_00 39:32

In welcher Reihenfolge wird es Sachen? Genau, Reihenfolge. Und was auch manchmal hilft, ach ne, wir sind noch nicht bei Backlog, aber was manchmal hilft, weil das, also Roadmap und Backlog und... Du kannst auch den perfekten Übergang machen. Ja, genau. Also Missionen und Ziele hängen so ein bisschen zusammen wie Roadmap und Backlog. Also weil man mischt es auch gerne mal. Es werden dann immer Sachen in den Backlog geworfen, die eigentlich in die Roadmap müssten und so weiter und so fort. Aber man kann sich auch das gerne vorstellen, dass man den Backlog nicht so in diesem linearen Jira-Backlog denkt, sondern eher als Tortendiagramm. Also du musst dir vorher überlegen, wie viel Zeit hast du für bestimmte Sachen. Das schneidet dann wie so ein Stück Torte aus diesem Kreis aus. Und das, was dann noch übrig bleibt, ist dann das, was du eigentlich für deine Mission und für deine Ziele hast. Das sind die Kapazitäten dafür. Und mehr passt da nicht rein. Und dann überleg dir, wie viele Lanes du da offen haben kannst. Wie viele Epacks du gleichzeitig in einem Team bearbeitet bekommst.

SPEAKER_03 40:25

Ja, finde ich gut, weil man dann gezwungen ist, in dem Kontext, in dem Rahmen halt, sich auch im Vorfeld Gedanken zu machen, so okay, ist dafür Zeit oder nicht.

SPEAKER_00 40:32

Und es gibt eben Sachen, die nicht verhandelbar sind. Man verhandelt die trotzdem oft, aber sie sind halt nicht verhandelbar.

SPEAKER_03 40:38

Beispielsweise Support-Themen, Bugfixes oder sowas. Genau.

SPEAKER_00 40:42

Und wenn man, also jetzt Add-on plus, immer die Sachen, die man doch wichtig fände, also so Weiterbildung, Refactoring, diese Sachen, die immer runterfallen. Wenn man das schafft, dass die auch noch nicht verhandelbar sind in diesem Trottendiagramm. Das wäre doch schön.

SPEAKER_02 41:00

Cool. Wie ist es konkret? In welcher Form bringt ihr das unter? Also. Mag jetzt komplett vollständig.

SPEAKER_00 41:14

Ja, voll konkret, danke.

SPEAKER_02 41:18

Du hast ja gesagt, aus dem Ganzen hat es jetzt einen Namen gegeben. Wie wird es denn implementiert? Also hält man die Ziele irgendwie schriftlich fest? Ist er eine Präsentation? Also wie es einfach so, wie macht ihr das im Moment, um das zu leben? Also was sind Tools, die ihr nutzt, sind das, genau. Du hast irgendwie gerade von Gyra-Tickets oder Boards geredet oder wie auch immer. Gibt es da schon irgendwas, was du sagen würdest oder sagst du, die theoretische Ebene reicht erstmal?

SPEAKER_00 41:43

Naja, die reicht natürlich nicht, aber gerade eben sind wir da noch bei der Anarchiephase. Es ist sinnvoll, das aufzuschreiben. Mit meinem Team habe ich viele auf Figma-Boards stehen. Es ist visuell, es ist für alle zugänglich, es ist einfach. Also ich würde immer das nehmen, was einfach ist und was reicht. Für uns reicht das gerade. Ansonsten, die Tickets sind natürlich im Tür. Okay. Es ist wichtig, dass man das kommuniziert. Das ist nichts, was man geheim hält für sich. Und wenn man jemanden fragt, dann gibt man vielleicht ein bisschen was Preis. Man muss damit rausgehen, man muss irgendwie in Kommunikation drehen, den Leuten sagen, das haben wir vor, das ist das, woran wir uns festhalten. So das passiert jetzt noch nicht so viel, aber das theoretisch, wenn es da Konflikte gibt, weil irgendwie Sachen nicht zusammenpassen, dass man eben den Raum schafft, um das überhaupt aufzudecken. Das ist auch eine Art von Messbarkeit.

SPEAKER_02 42:32

Okay. Also es ist eigentlich grundsätzlich super individuell, was das Unternehmen angeht, wie da die Prozesse und Strukturen sowieso sind und man versucht es dann einfach daran zu erleihen und die Kommunikations- und sonstigen Mittel zu nutzen, die auch sonst genutzt werden.

SPEAKER_00 42:46

Genau, man fängt jetzt an der einen Stelle an und dann schaut man, wie man weiterkommt.

SPEAKER_02 42:51

Okay.

SPEAKER_00 42:53

War das die Antwort?

SPEAKER_02 42:55

Ja, also keine Ahnung, hätte auch sein können, ich habe hier so ein Vision to Act-App gemodet. Das kommt später.

SPEAKER_00 43:04

Also das Buch, das Tool, das kommt alles später.

SPEAKER_03 43:08

Schreibst du gerade ein Buch?

SPEAKER_00 43:10

Nee, noch nicht. Ich muss das noch nicht mal einen Blog eintragen. Nee, ich mach gleich ein Buch draus.

SPEAKER_03 43:17

Ja, eine vorletzte Folge, da hat die Gästin auf jeden Fall ein Buch geschrieben. Das fand ich sehr interessant. Ja, vielleicht kommt das ja noch.

SPEAKER_00 43:24

Da komme ich dann noch.

SPEAKER_02 43:25

Hättest du denn schon einen Blog, wo du den Beitrag veröffentlichen kannst?

SPEAKER_00 43:28

Nee, noch nicht.

SPEAKER_02 43:29

Okay, das wäre auch Teil davon. Na gut. Oh, das wäre aber eigentlich sehr gut.

SPEAKER_00 43:33

Ich meine, hat es eine Mission. Okay, meine Mission ist das Veröffentlichen. Ziel, Block finden, Text schreiben.

SPEAKER_02 43:42

Sehr schön. Natürlich, aber das würde jetzt eher den Druck, die Druckhumber wieder erhöhen und nicht, dass man die Sachen nicht parallel machen soll. Das ist eigentlich sehr kontraintuitiv, das wir jetzt zu tun. Ich wollte gerade vorschlagen. Naja, wir können ja so lange warten mit der Veröffentlichung der Folge. bis du diesen Blogartikel hast, damit wir das direkt, damit du es direkt raus.

SPEAKER_00 44:07

Weißt du, wie lang eure Urlaufzeiten sind. Bis nächste Woche.

SPEAKER_02 44:14

Also wenn es schon was gäbe, dann verlinken wir das noch nicht gerne in den Shownotes. Ja, ich kann nicht.

SPEAKER_00 44:18

Ich kann ja mal schauen. Also diesen Monat schaffst du es.

SPEAKER_02 44:20

Google Alert kann man, gibt es noch? So Google Alerts sind so Besuchbegriffe. Paula Ostmann, Vision to Act und dann kommt das direkt reingespült, so am Ende.

SPEAKER_03 44:30

Ein Aspekt, auf den ich noch eingehen wollte, weil wir den vorhin kurz angeschnitten haben, ist natürlich Stichwort Agilität. Weil es gibt ja also durchaus, man ist ja nicht im luftlehrenden Raum mit seinem Produkt und seinem Team. So, es gibt ja viele Einflussfaktoren. Beispielsweise etwas, was sich im Team verändert, strukturell, ein Teammitglied verlässt das Team. Gleichzeitig gibt es ja auch externe Faktoren, wie beispielsweise, du hast gesagt, die Arbeit mit Banken zusammen. So, da könnten ja neue Auflagen irgendwie entstehen, was auch Datenschutzkonformität und sowas angeht. Gleichzeitig gibt es ja auch so etwas wie man pivotiert am Markt. Beispielsweise so, hey, ja bisher Banken hat sich voll angeboten, aber jetzt sehen wir zum Beispiel, keine Ahnung, die Deutsche Bahn oder so ist ja voll der gute Kunde. Wir müssen aber unser Produkt ein bisschen shiften dadurch. Und jetzt ist der richtige Zeitpunkt dafür. Wir können nicht warten. Wie reagiert dieses Modell generell so ein bisschen auf so externe Faktoren und wie bleibt man damit agil?

SPEAKER_00 45:21

Ist jetzt das vier auf einmal. Also erstmal, wie reagiert das Modell darauf? Wenn ich eine Veränderung habe, dann muss ich schauen, passt es zu dem, was ich mir vorher überlegt habe? Also ich habe eine Veränderung, das macht was mit meinem Backlog, das macht was mit meiner Roadmap. Also irgendwo findet diese Veränderung statt. Sagen wir, ich habe eine Veränderung in meiner Roadmap, weil ein neuer Kunde und es müssen jetzt irgendwie ganz neue Sachen da irgendwie rein. Und dann muss ich schauen, passt es zu meinen Zielen? Passt es zu meinen Zielen super? Wenn es nicht passt, ich kann es aber auch nicht ändern, also wenn es nicht passt, kann ich jetzt sagen, nee, dann kann ich es nicht machen. Oder ich stelle fest, ich kann es nicht ändern, weil wir haben jetzt immer den neuen Kunden und ich kann jetzt nicht aber Nein sagen. Das heißt, dann muss ich schauen, dass ich meine Ziele review. Ich muss meine Ziele anpassen. Dann passen die nicht mehr zu der Situation, also muss ich sie neu machen. Und dann bleibe ich am Track und muss halt schauen, passt es auch noch zu meiner Mission? Oder es hat sich dann meine Mission auch schon noch komplett geändert. Das kann ja auch noch passieren.

SPEAKER_03 46:14

Also genau, es ist kein festes Konstrukt, sondern man muss selbst immer regelmäßig mit sich ins Gericht gehen, passt das noch? Das ist gerade die aktuelle Frage.

SPEAKER_00 46:20

Genau. Und jetzt zu dem Agilteil, deswegen habe ich das gerade rausgelassen. Das finde ich deingend ganz spannend. Was heißt denn agil für dich? Das frage ich immer alle. Ich bin immer gespannt auf dich.

SPEAKER_03 46:32

Die Frage leite ich an meinen Co-Host Dennis weiter. Nein, also ich kann das sehr gerne anfangen. Agil bedeutet für mich eine Form von Anpassungsfähigkeit auf jeden Fall, so dass man relativ schnell auf Veränderungen reagieren kann. Seien sie intern oder seien sie extern. Genau. Ja, das ist für mich agil. Also schnelle Anpassungsfähigkeit würde ich sagen.

SPEAKER_00 46:56

Das eigentliche Wort agil sozusagen nicht. Also es gibt ja agil großagil und klein agil.

SPEAKER_03 47:01

Oh, wirklich?

SPEAKER_00 47:01

Ja, so wird das oft transkripiert.

SPEAKER_03 47:03

Das heißt, glaube ich, auch beweglich einfach, oder? Also wortwörtlich übersetzt, beweglich. Dennis, du wolltest was sagen?

SPEAKER_02 47:11

Für mich ist es maximal wenig Prozesse. Oh.

SPEAKER_00 47:18

Okay.

SPEAKER_02 47:24

Scheint nicht maximal überzeugt über diese Antworten.

SPEAKER_00 47:28

Nee, also es ist nicht falsch. Also was es natürlich trifft, ist, dass man bei Agilität vor allem auch immer von Einfachheit redet. Also es gibt ja diese agilen Werte und eins davon ist Einheit und ich glaube, das wird auch oft vergessen. Von daher ist maximal wenig Prozesse, glaube ich, dahingehend ganz gut. Dass man sagt, nur so viel, wie eben notwendig ist. Deswegen musste ich kurz drüber nachdenken. Danke. Dieses auf Veränderung reagieren, finde ich an sich auch gut. Für mich heißt das, deswegen habe ich gefragt, weil ich nicht so einfach sagen kann, was das agil in meiner Pyramide da zu tun hat. Für mich heißt agil sein, das ist einmal kontinuierliche Verbesserung. Also dass man die ganze Zeit schaut, was ist dieser Lernzyklus. Also ich bin in einem Zustand, ich beobachte, was ist mein Zustand, was könnte ich besser machen. Ich setze das um ein Experiment und schaue in welchem Zustand ich rauskomme. Und im besten Fall ist das eine Spirale, die nach oben geht, das heißt, ich werde immer besser. Und das wende ich an, nicht nur auf die Art, wie ich arbeite, sondern auch auf die Strukturen, mit denen ich arbeite. Also agiert heißt eben nicht, ich mache was ich will, ich reagiere irgendwie super schnell auf alles, sondern ich habe einen recht klaren Rahmen, in dem ich mich bewege. In dem kann ich mich frei bewegen, aber dieser Rahmen ist recht klar, auf den haben wir uns geeinigt. Der wird aber eben in sinnvollen Abständen reviewed. Also wir können die Strukturen, in denen wir arbeiten, ändern, aber halt nicht ständig, sondern in bestimmten Abständen und verbessern sie dadurch immer mehr, sodass wir uns eben in maximaler Leistungsform befinden. Das war jetzt nicht so catchy ein Satz, aber genau. Oder ein Wort, das heißt ein bisschen besser. Das heißt es für mich. Und genau, also man kann jetzt wahrscheinlich ewig darüber reden, was heißt agil, was heißt nicht agil, wie wird das gelebt. Aber die Pyramide passt dahingehend sehr gut rein, weil ich eben Feedbackzyklen habe. Also ich habe Möglichkeiten, Sachen immer wieder zu verbessern und anzupassen. Gleichzeitig habe ich aber einen klaren Rahmen, in dem ich mich bewege. Also ich habe mir einmal überlegt, was möchte ich, wo möchte ich hin und in diesem Rahmen bewege ich mich dann. Und es ist aber auch minimal, das ist ganz einfach. Möglichst wenig Strukturen.

SPEAKER_03 49:36

Cool. Sehr cool.

SPEAKER_00 49:40

Jetzt habe ich irgendwie totgeredet.

SPEAKER_03 49:42

Nee. Hast du noch Fragen, Dave? Ja klar. Genau, weil es ist auch ein Aspekt, den wir. Ich habe das schon im Blick. Genau. Was hast du im Blick?

SPEAKER_02 49:52

Die Uhrzeit. Die Uhrzeit. Die Uhrzeit. Im Vorgespräch habe ich gesagt, Paula, in der Regel haben wir nicht das Problem, dass wir zu kurz haben oder denken, das ist nicht Inhalt, sondern es geht eher in die andere Richtung. Und auch heute können wir uns wieder sehr gut enthalten, aber es ist noch alles gut. Wir sind noch. Genau, wir sind komplett on track. Genauso wie du, Dave, dir das ausgedacht hast.

SPEAKER_03 50:10

Richtig. Wir sind zeitlich genau da, wo ich gedacht habe, wo wir bei Minute 52 sind. Das ist krass, ne? Die Zeit fliegt ja. Das merkt man ja nicht. Wenn man Spaß hat, genau. Ich würde ein bisschen übergehen zu so einer Art Bewertung oder Empfehlung. Also es sind ja auch Leute, die zuhören und auch in Teams arbeiten und die damit irgendwas anfangen sollen, dann im Endeffekt. Und da für die Leute wahrscheinlich nochmal wichtig zu hören, aus deiner Sicht, was ist für dich so der größte Vorteil dieses Modells? Inwiefern enabled das Teams richtig?

SPEAKER_00 50:46

Der größte Vorteil ist, wenn ich mich über wenn ich zu viel Arbeit um mich herum habe und ich sehe nicht durch, wie ich das alles schaffen soll oder was wir jetzt am besten als erstes machen oder wie wir irgendwie Ordnung da reinbringen, dann hilft mir das, eine Klarheit und Struktur reinzubringen. Und zwar auch auf eine Art und Weise, dass man das gemeinsam macht. Also man kann als Team gemeinsam da Ordnung und Struktur reinbringen, an der man sich entlanghangeln kann. Damit man eben nicht immer wieder verloren ist und nicht immer wieder nach einem halben oder einem Jahr dasteht und sich fragt, jetzt haben wir denn unsere Ziele schon wieder nicht erreicht.

SPEAKER_03 51:22

Das heißt, auf der Kehrseite, wenn man das Gefühl hat, so, hey, in meinem Team ist alles super geordnet, super strukturiert, so, da lohnt es sich jetzt nicht, das einfach nochmal drauf zu wälzen, das System.

SPEAKER_00 51:32

Habt ihr solche Teams, wo man sagt, hey, es läuft, also es ist ja Wahnsinn, also ihr seid alles super sortiert. Wow. Nee, also ich meine, wenn es gerade gut läuft, muss man jetzt natürlich kein, nicht nochmal alles aufwühlen. Es kann natürlich auch Vorteile bringen, dass man es nochmal ein bisschen ordnet und so weiter. Aber ja klar, wenn man jetzt gerade happy und zufrieden ist, dann ist es gut. Man sollte immer das machen, was man selber braucht. Das sind wir wieder bei der Einfachheit. Also man macht das, was gerade gebraucht wird.

SPEAKER_03 51:58

Möglichst wenig. Möglichst wenig. Ich glaube, aber das ist halt sehr schwierig zu beurteilen. Also ich glaube, gerade für irgendwie sehr neue, frische Teams auch so, irgendwie zu beurteilen, so was brauchen wir gerade, was fehlt uns, was könnte uns helfen. Es ist, glaube ich, gar nicht so einfach, das dann zu erkennen.

SPEAKER_00 52:12

Aber dann fängt man einfach wieder von vorne an und sagt, wo wollen wir denn hin? Was brauchen wir denn da?

SPEAKER_02 52:17

Da sind wir bei dem Modell.

SPEAKER_00 52:18

Ja, das meine ich halt.

SPEAKER_02 52:21

Und man lernt ja auch damit, den Umgang damit. Also ich finde, das ist ja auch irgendwie, was man sieht, in Teams sehr unterschiedlich sind und je nachdem, wie weit ein Team ist in meiner Vorstellung, desto weniger braucht es auch vielleicht davon. Weil es halt vieles automatisiert macht. Und je frischer oder unorganisierter oder unklarer oder so weiter, desto mehr helfen auch dann solche Tools, genau das reinzubringen.

SPEAKER_03 52:50

Wo es eventuell dann sogar Teams ausbremsen könnte im ersten Fall so, wenn irgendwie so alles klar ist und so alles, komm, lass mal schnell pushen oder so, wenn man das in der Natur zu sehr irgendwie Strukturen versucht reinzubringen, dass es dann einen doch erstmal hemmt.

SPEAKER_00 53:02

Genau, man muss auch keinen Staub aufwirbeln, wo gerade alles gut ist.

SPEAKER_03 53:07

Dennis, hast du noch eine Frage? Keine inhaltliche.

SPEAKER_02 53:12

Eine persönliche? Ja. Oder eine. Nee, dürfen die Leute dich kontaktieren, Paula, wenn sie Fragen oder Anregungen zu diesem Modell haben?

SPEAKER_00 53:24

Natürlich, sehr gern.

SPEAKER_02 53:25

Okay. Und dann haben Sie über den LinkedIn oder den Blog? Den Blog, ja. Auf LinkedIn, ja, einfach auf LinkedIn.

SPEAKER_00 53:31

Paula Ostmann, einfach schreibt mir. Sehr gern. Ich rede gern drüber.

SPEAKER_03 53:35

Sehr gut. Sehr cool. Dann haben wolltest du. Nein, nur die Hand gehoben, brauch weiter. Genau. Dann wie immer am Ende unseres Deep Dives gibt es eine Frage, die ich sehr gerne stelle. Und zwar, wenn man jetzt quasi die letzten 50 Minuten nicht so toll zugehört hat und sich eine Sache rausnehmen sollte, was besonders wichtig ist, was wäre es denn aus deiner Sicht, was man sich hier auf jeden Fall mitnehmen sollte?

SPEAKER_00 54:07

Wenn alles zu viel ist, wenn zu viel Arbeit ist, wenn wir nicht wissen, wo wir anfangen sollen, fang einfach immer wieder am Anfang an, ganz oben, bei der Mission online zielen. Wer bist du und wo möchtest du hin? Und dann kannst du dich daran runterhangeln und priorisieren, was gemacht werden muss und was nicht.

SPEAKER_03 54:26

Gut, das war schön. Das waren schöne Abschlussworte. Fandest du die Frage gut?

SPEAKER_02 54:30

Nee, aber geschlossen, ja, aber Paula hat es trotzdem sehr schön, also in dem Fall hat sie sehr schön abgebunden und das war ein schönes Ende der Folge. Aber es war auch einfach inhaltlich nicht ganz richtig zu sagen, das ist die Standardfrage, die wir stellen, denn das haben wir nämlich noch nie gesehen.

SPEAKER_03 54:50

Nein, nein, nein, das ist meine Standardfrage. Achso, wenn ich moderiere.

SPEAKER_02 54:54

Die hast du heute neu eingeführt. Das ist die Standardfrage, wenn ich moderiere. Okay. Das ist eine tolle Frage. Oder? Ja. Ja. Weil auch nach den 15 Minuten, wenn nicht keiner dazugehört hat, der hört auch die letzten zwei Minuten. Aber dann schneiden wir das einfach direkt an den Anfang. Stimmt.

SPEAKER_00 55:06

So ein Preview. So ein TLDA am Anfang. Genau, TLDA am Anfang.

SPEAKER_03 55:09

Dann lohnt sich es am meisten. Sehr gut. Neues Format. Neues Format. Hatten wir schon mal probiert, war nicht gut. Gut, dann an der Stelle, Paula, vielen Dank. Es war eine sehr, sehr angenehme Folge.

SPEAKER_00 55:21

Ja, vielen Dank, dass ich hier sein durfte.

SPEAKER_03 55:23

Ich fand's sehr, sehr gut. Dennis, auch dir, danke nochmal als Co-Host. Du hast einen fantastischen Job gemacht heute.

SPEAKER_02 55:29

Dieses Lob kann ich natürlich nur zurückgeben, Dave, an seine erste anmoderierte Folge, die du hattest. Und auch besonders an dich, Paula. Du hast ja, glaube ich, ein bisschen. Ich weiß nicht, ob Zweifel zu groß ist, aber ein bisschen Unsicherheiten, ob ein Podcast was ist. Ja, mein erster Podcast ist und ich mein Bauchgefühl sagt, ja, das war eine sehr gute Folge. Okay, ach das Freund. Es hat wirklich Spaß gemacht, mit dir zu reden. Es war sehr, sehr angenehm. Geh in Podcast. Okay. Also ich würde auch das, es wäre schön, wenn man sich, Vision Direct, fände ich gut, wenn das ein großes Ding wird, die Pyramide. Und wenn wir es dann genau dann recherchieren.

SPEAKER_00 56:05

Wenn ich angegeben habe, habe ich das nicht durchdacht, dass das muss das so werden. Das war irgendwann so, wie nenne ich das?

SPEAKER_02 56:16

Und dann so eine Recherche, fragst du die KI und du kommst irgendwie, hä, und dann ja, wurde erstmals erwähnt, der Programmierbar-Podcast. Das ist gut. Oh, das ist wirklich sehr gut.

SPEAKER_03 56:24

Ja, ja, sehr schön. Alright, dann, bevor wir die Folge komplett beenden, lasst gerne Feedback da unter podcast.programmier.bar. Wir reagieren auf alles. Schreibt uns auch in den Kommentaren bei Spotify, Apple Podcasts und wo sonst auch immer. Ich glaube, ja, nichts bleibt ungelesen von uns. TikTok, ist neue Ding. TikTok. Oh, stimmt. Da hast du sogar einen Hate-Kommentar an mich gemacht. Ich erinnere mich. Ansonsten vielen Dank fürs Zuhören. Habt einen wundervollen Tag und wir sehen uns ganz bald wieder. Tschüssi. Bis dann. Mach's gut. Danke, Paula.