Deep Dive 210 –

Vision to Act Pyramide mit Paula Ostmann

23.06.2026

// Podcast
// Deep Dive 210

Shownotes

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.

Download

/transkript/programmierbar/deep-dive-210-vision-to-act-pyramide-mit-paula-ostmann

Dave: Hallo und herzlich willkommen zu 1 neuen Aufnahme der programmier.bar. Ich grüße euch grade hier aus dem schönen Vodafone 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, Dev of Teams, was deren Microsoft Teams. Microsoft Teams, genau, 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
Dennis: ich hier sehen kann.
Dave: Und wir haben uns natürlich ein Profi mit ins Studio geholt. Dave Proschitzki.
Dennis: Das ist der Profi.
Dave: Sorry. Also alles gut. Ist doch was?
Dennis: Wir schneiden gar nichts raus. Wir machen einfach weiter. Wir
Dave: machen einfach weiter.
Dennis: Ja, denn liebe Hörer*innen, das war Daves erstes Intro in 1 Deep Tail Folge.
Dave: Das war bisher ganz gut.
Dennis: War bisher ganz gut. Bis auf, dass Du deinen Namen vergessen hast.
Paula: Ich hab
Dave: einen Namen für Ach, ich hab einen Namen vergessen. Ja. Jo, ich bin natürlich Dave, Dave Krusitzky. Moin. Und neben mir sitzt die Paula. Hallo Paula, schön, dass Du da bist.
Paula: Hallo, schön, hier zu sein.
Dave: Paula, einfach mal 'n bisschen für die Zuhörerin jetzt klarzumachen, wer Du bist, magst Du dich mal kurz selbst vorstellen?
Paula: 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 hab Physik studiert und in Physik promoviert.
Dave: Mhm. Find ich erst mal 'n spannender Werdegang von Physikstudium zu jetzt Engineering Manager.
Paula: Kannst Du
Dave: mal bitte den Weg hier kurz näherbringen?
Paula: Kurz skizzieren? Ja. Ja, also in der Physik, also vor allem hab ich ihn theoretischer Physik probiert. 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.
Dave: Matlab kenn ich auch noch.
Paula: Matlab kann man nehmen. Ich war son bisschen, also ich hab alles in c plus plus gemacht. Okay. Aber man kann natürlich Matlab nehmen oder Python wäre eigentlich so die Wahl für die meisten Physiker, genau. Mhm. Genau, ich bin da abgedriftet, wer weiß. Genau, also dadurch hatt ich sone 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.
Dave: Mhm.
Paula: Genau.
Dave: Da hab
Paula: ich erst als Systemingenieurin gearbeitet und dann ging das so in diese ganze Teamleitungsrolle und jetzt bin ich Engineering Managerin.
Dave: Aha, okay.
Dennis: Und was macht ihr bei Elevate?
Paula: Wir automatisieren Arbeitsprozesse, die sich sehr, die eben sehr wiederholbar sind, sag ich jetzt mal, ne. Also wir haben große Kunden, die viele Daten haben, die so von vielen Kunden kommen. Also der klassische Fall, wir arbeiten mit 'ner großen Bank zusammen. Das heißt, sie haben viele Kunden, die sich für 'n Kredit bewerben oder die eben sagen, hier ist meine, ich möcht meine Adresse ändern oder irgendwelche Daten eben schicken dahin. Und oft müssen die Firmen das noch selber irgendwo eintragen in dieses Thema. Also es ist so halb manuell. Mhm. Und das können wir automatisieren, weil es ist ja sehr repetitiv. Also das kann ich ja einfach, es ist nicht einfach. Ich kann das ich kann das eben automatisieren. Und das machen wir mit AI, weil wie sonst? Und genau, also wir nehmen diese Daten, extrahieren die, packen wir in die Systeme, die sie eben nutzen. Und wir machen auch noch mehr, aber das ist so das, die Kernidee.
Dennis: Ist das AI, wie nennt man das? Native, AI first, AI, also wie lange gibt's das Unternehmen schon?
Paula: Ist das Unternehmen seit viereinhalb Jahren.
Dave: Ah, okay. Okay. Klingt fast sogar Namen. Aber ist das,
Dennis: ist das in dem Namen von Elevate Ach
Paula: so, Du guckst jetzt Ich guck jetzt aber
Dennis: ganz schön, weil da Stelle, weil da steht der Elevate GMBH und da steht
Dave: Ich dachte mir, coole Schreibweise, aber hab's gar nicht hinterfragt. Nee, ja,
Paula: das das a I steht für AI0.
Dave: Das ist ja superschlopp.
Dennis: Dann war ja auch schon recht border Move oder? Vor viereinhalb Jahren, na gut. Ja, genau. Ja, trotzdem, aber ja, okay. Ja.
Paula: Ja, also ich glaub, die Genese der Firma geht noch 'n bisschen weiter zurück. Also es gab eben noch Projekte vorher und so weiter. Aber genau, man hat da rechtzeitig auf eben machine learning gesetzt und auch Knowledge Graph, weil's das auch 'n Begriff ist. Mhm. Das sind so die 2 Bausteine.
Dennis: Okay. Und Du bist da seit
Paula: Einem Jahr. Einem Jahr. Genau. Okay.
Dennis: Und da wir ja 'n bisschen über so Teamstrukturen und Teams sprechen und so was, ist wahrscheinlich auch interessant, so ganz kurz mal, wie groß ist im Moment Elevate? Für wie viele Leute bist Du verantwortlich?
Paula: Also Elevate selber ist ungefähr sind wir 100 Leute. Mhm. Verteilt auf 2 Standorte. Also wir haben noch einen Standort im Schwarzwald in Trieberg. Mhm. Und die meisten sitzen aber in Dresden oder remote, wie das eben so sich verteilt. Vielleicht mal kurz zur Struktur 'n bisschen. Also wir haben so den, es gibt so diesen Business Teil, Sales und so weiter. Und dann gibt's den technischen Teil, wo wir die Entwicklerteams haben. Ich muss noch mal zählen, ich denke, wir haben 11 Entwicklerteams. Son bisschen angelehnt an Team topologies. Also wir haben versucht, diese Screen Allineteams für die Produktentwicklung zu machen, ne. Das sind die Featureteams. Wir haben ansonsten noch Appication 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 Plattformteams. Und 1 der Plattformteams ist 1 meiner Teams, das ist das DevOps Team, für das ich verantwortlich bin. Ansonsten hab ich auch noch ein Application Team. Das sind die 2 Teams, die ich manage.
Dave: Mhm.
Paula: Du überlegst so, das passt sehr gut zusammen, weil das, was man onboarded, ist natürlich auch das, was man irgendwie
Dennis: Ja, nein, ich auch, weil ich überlege, je 100 Leute, dann finde ich 10, 11 Teams relativ viel. Die Entwicklungsteams hast Du die genannt, ne. Das heißt, sie haben schon alle irgendwie so 11 Personen, oder?
Dave: War das?
Paula: Nee, nee, nee, nee.
Dave: 11 Teams.
Paula: Ja. Genau, ich muss noch mal 18, aber ich glaub Ja,
Dennis: aber grob. Und wenn die wie groß sind ungefähr?
Paula: Ja, so alles zwischen 3 und was ist denn das größte Team 6. Ah, okay.
Dennis: Ja, dann sind wir okay.
Paula: Ist eigentlich schon die die größte aber der 3
Dennis: große, okay.
Dave: Du weißt da.
Paula: Also wir haben schon den Großteil der Leute arbeitet in der Entwicklung in der Firma.
Dennis: Ja, okay.
Paula: Deswegen
Dennis: Ja, gut, wenn's wenn's 3 bis 6 ist, dann passt das auch. Ne, dann sind ja irgendwie, weißte nicht, 40 oder so was, die die nicht genau in diesen Teams arbeiten. Ich hab irgendwie grade von größeren, so hab dann an 6, 7 Leute gedacht. Und dann wird's natürlich irgendwie schon knapp mit den mit den anderen Rollen. Ja. Aber okay, cool, okay. Ja.
Paula: Dann haben wir natürlich diese anderen Rollen, die man immer hat. Produktentwicklung, Projektmanagement, Architekten, Engineeringmanager. HR? HR natürlich, genau.
Dennis: Okay. Sehr gut.
Dave: Ja. Vielleicht 'n bisschen zum Kontext, warum wir auch bei Vodafone sind. Wir haben dich hier direkt von der DecomPilot Konferenz abgegriffen. Mhm. Und da hast Du 'n Vortrag gehalten mit dem Titel, der no Awards for biegende busyest. Kannst Du 'n bisschen darauf eingehen, was Du mit genau meinst?
Paula: Gerne. Also meine Beobachtung ist, dass wir alle immer zu viel Arbeit haben. Immer, die ganze Zeit. Euch geht das mit Sicherheit auch so nah. Es gibt immer so viele Sachen, die wirklich aufn Tisch liegen und jetzt gemacht werden müssen. Und dann gibt's noch diesen Stapel an Sachen, die man gerne mal machen würde, also diese ganzen 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, da rauszukommen? So 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, die auf die's ankommt, dass man eben diese Awards bekommt, ne. 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's an und da wollen wir hin.
Dave: Mhm. Und Du hast grade schon angesprochen, so es gibt natürlich nicht die Methode, aber es gibt natürlich eine Methode, die man nutzen kann, das möglich effizient zu gestalten. Ich glaub, eine eine Aussage von dir war auch so, Zeit ist das ultimative Asset so, das das, was am meisten wertgeschätzt wird. Mhm. Und diese Zeit sollen wir möglichst am besten nutzen und dann mit da am besten an den richtigen Dingen zu jeder Zeit zu arbeiten. Und da hast Du eine Methode vorgestellt. Magst son bisschen darauf eingehen?
Paula: Sehr gerne. Also es ist 'n einfaches Modell, was ich benutze, mit meinen Teams zu arbeiten. Die Idee ist, dass wir erst mal anfangen mit 'ner Pyramide. In der Pyramide sind 4 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 irgend 'ner Form mal mehr oder weniger gut organisiert, aber versuchen das jetzt Kohären aufzubauen, indem man eben immer von oben anfängt. Ja, also man fängt immer mit der Mission an. Das ist das Warum. Warum bin ich da? Ja, was ist meine Identität? Daraus kann ich meine Ziele feststellen, ne. Also was ist dieser Award, den ich haben möchte? Und daraus leite ich meine Roadmap ab, da komm, wie komm ich dahin und mein Backlog ist dann mein Daily Doing. Und die Idee ist, dass man das eben immer nacheinander ableitet, voneinander ableitet.
Dave: Mhm. Genau.
Dennis: Du hast grade gesagt, dass dann für mich oder für eine Person, ist es eher so ein individuelles Ding oder ein Team Ding?
Paula: Wie Du möchtest. Mhm. 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 son bisschen mit einplanen muss. Aber im Prinzip kann man das in jedem Kontext nehmen. So, man staffelt ja auch gern, ne, die Ansicht von diesem Individuumteam Firma. Das geht so nach außen und Du könntest es auf allen Ebenen benutzen, wenn Du möchtest.
Dennis: Wie setzt ihr's konkret ein?
Paula: Grad eben benutz ich's vor allem mit meinen Teams. Wir versuchen das auch auf Firmenebene grad umzusetzen oder wir setzen's grade aber da wir da grad noch so am Anfang sind, möcht ich da jetzt gar nicht so große Erfahrungswerte schon teilen. Ne, das braucht noch, das muss noch 'n bisschen greifen und auch noch 'n paar Iterationen, da besser zu werden. Wir sind ja agil Continuous improvement.
Dave: Ja. Ach so, das ist etwas recht frisches, dieses Konzept, was ihr einbaut?
Paula: Meine Pyramide?
Dave: Genau.
Paula: Oder das Modell?
Dave: Genau, genau.
Paula: Na, frisch. Also ich nehm, ich glaub, ich nehm das schon an sich eine eine Weile, aber dass ich's jetzt mal so ganz ordentlich aufgeschrieben hab, das hab ich jetzt grad für die die ComPPHEIT mal gemacht.
Dave: Ach, okay, okay. Genau.
Paula: Also grade es gehören eben noch 3 Regeln dazu, die man nutzen muss, nicht nur an sich eine Kohärenz zwischen den Baustellen zu finden, sondern auch noch eine zeitliche Kohärenz zu finden, ja, weil diese Dinge ändern sich. Mhm. Ne, also meine 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 hab immer externe Kräfte, die darauf einwirken, dass die Dinge nicht so laufen, wie ich sie geplant hab. 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 4 Bausteinen, dass das entweder gecheckt wird, ob das mit der Ebene drüber noch passt oder dass ich schaue, dass ich 'n Review von meiner ganzen Pyramide mache. Ja. Also wenn sich wenn sich die Situation komplett ändert und meine Ziele einfach nicht mehr passen, dann muss ich sie anpassen. Mhm. So, das ist die Idee dahinter. Ja. Und dass ich das jetzt mal so ordentlich aufgeschrieben hab und präsentabel gebracht hab, das ist das war jetzt der Anlass hier. Genau.
Dennis: Okay, ja. Ich hab eine Frage. Dave, Du warst Dann
Dave: nee, fragt Du zuerst. Frag Du zuerst. Ich wollte 'n bisschen Struktur reinbringen.
Dennis: Ja, sorry.
Dave: Aber nein, aber mach gern. Was war was war deine Frage gewesen?
Dennis: Die Frage, die Du auch gestellt hättest Genau.
Dave: Definitiv.
Dennis: Ist, Es gibt es 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 das ein Tool, was ich mir irgendwie einmal, Ahnung, im Jahr angucke und irgendwie mich da alleine? Ist es was, was ich so täglich eigentlich neben meinen Schreibtisch stellen könnte, weil ich immer mich immer wieder reminthen will, so, das ist eigentlich das, ne, von wo ich komme und wo ich hinwill? Oder was würdest Du empfehlen, wie wie stark der Umgang mit diesem mit diesem Tool ist?
Dave: Also ich
Paula: glaub, wenn man jetzt eine wirklich gute Mission und Ziele für sich gefunden hat, wär 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, ne. Also es sollte was sein, was präsent ist und klar ist, aber es sollte einen nicht permanent beschäftigen.
Dennis: Mhm.
Paula: So. Also man setzt es einmal auf und dann gibt es erst mal Struktur. Gleichzeitig sollte man's aber nicht erst 'n Jahr später angucken, weil da kann ich versprechen, dass man davon abgekommen ist. Da werden Sachen passieren, die mich vom Weg abbringen. Ja. So. Und das heißt, man muss sich vorher überlegen, was ist 'n guter, das wieder anzugucken? Und das kann ich jetzt nicht sagen, was das fürn Team genau bedeutet, das muss man selber entscheiden. Mhm.
Dave: Ich find,
Paula: es gibt so natürliche Zyklen, in denen man das machen kann, ne. Also wer Sprints macht, man guckt so oder so alle 2 Wochen in seinen Backlog rein. Mhm. Dann review ihn auch. Schau, was der ordentlich passt das? Ist das die Dynamik, die ich erwartet hab? Na, also ich weiß nicht, wie die Backlogs bei euch aussehen, aber die, mhm, ja. Cool. Voll, genau.
Dennis: Lief cool doch. Gar nicht mehr. Ja, ey, ey ist doch da.
Dave: Ah ja, stimmt, sie macht das einfach.
Dennis: Ist ja alle leer.
Paula: Ja, aber er arbeitet alles ab.
Dave: Backlog ist weg.
Paula: Aber son voller Backlog ist nicht gut. Also 'n 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. Sone, und son Review, das so alle, ob das jetzt alle 2 Wochen immer klappt, aber man sollte sich's vornehmen. Sone Roadmap, wenn man jetzt 'n stabiles Team hat, was jetzt nicht in 'nem engen Projekt ist, das sollte schon alle 3 Monate irgendwie noch mal angeschaut werden, passt es noch? Haben sich da fundamental Sachen geändert? Bei Zielen, ja, ich würd sagen, alle halbe Jahre sollte man mindestens mal drauf schauen, passt es noch? Spiegelt es noch die Situation wirklich wider? Und sone Mission von dem Team sollte sich jetzt nicht ständig ändern, das wär nicht gut, ja. Das ist dann sone red flag ist, glaub ich, was anderes im Argen. Aber so einmal im Jahr würd ich schon raten, dass man sich als Team Zeit nimmt und sich das wirklich mal anschaut. Und das braucht wirklich Zeit. Das ist nicht inner Stunde mal so zwischendurch gemacht. Man braucht da, man braucht Raum, man braucht Inspiration, man braucht auch Reflexionsmöglichkeiten darüber. Man kann nicht aber sagen, lies mal die Mission und sag mal bitte, ob das jetzt noch stimmt. Mhm.
Dave: Ich ich find das ja interessant. Ich kann ja auch 'n bisschen ausm Nähkästchen plaudern, weil ich ja auch Produktverantwortlicher bin bei uns. Und Wow. Das Je nachdem man sie rauskommt Nichts. Gleich wahr. Ja, es hat keine Lust mehr auf mich. Nein. Thema für eine andere Folge. Nee. Genau. Und ich ich grade auch gemerkt habe so, ich erkenn da viele Parallelen. Also ich glaub, bei uns ist oft so diese Quartalstruktur, wo wir dann zumindest hinterfragen, haben sich unsere Ziele geändert? Wenn nicht, übernehmen wir sie weiter, so. Unsere Mission beziehungsweise Sensiision ist relativ stabil. Aber ich merk halt trotzdem immer wieder in der Kommunikation mit meinen Devs, dass diese Unterscheidung zwischen Mission und Zielen gar nicht also so so einfach darzulegen ist. Wie würdest Du diese Sachen unterscheiden, diese beiden Aspekte Mission und Ziele? Mhm.
Paula: Ja, es wird auch schnell vermischt und also es ist auch, ich glaub, beide Konstrukte sind halt irgendwie sehr abstrakt, ne. Also was ist was ist eine Mission oder Vision, ne? Also was 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 nehm dazu immer gern das Beispiel von, wenn man jetzt mal son Hobbybeispiel nimmt für sich selbst, ne. Wenn ich jetzt sag, ich hab bin jetzt sehr ambitioniert sportlich, ich möchte was erreichen. Das heißt, ich sag jetzt, ich möcht jetzt mal meinen ersten Machathon laufen. So, mal 'n richtigen Award bekommen. Das ist 'n Ziel, ja. Das ist 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 jetzt sage, ich möchte einfach eine richtig gute Mitlife Crisis. Midlife Crisis, danke, dass Du das sagen.
Dave: Dann hättest Du mich nah dran
Paula: Gut, das ist nicht gesagt. Genau. Also ist meine Mission, mit meiner Midlife Crisis umzugehen? Oder ist meine Mission, ich möchte einfach eine richtig gute Langstreckenläuferin sein? Ja. 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 diese diesen Marathon gelaufen bin. Dann kann ich mir 'n neues Ziel setzen, meinen zweiten Laufen oder, ne. Ne. Während diese Ziele ja, sollten erreichbar sein und sollten auch was sein, was ja, nee, doch was man erreicht. Ja. Mhm. Es muss irgendwie 'n Definition auf dann für mein Ziel haben.
Dave: Mhm. Und eine Sache, über die Du also davor gesprochen hast, ist son bisschen grad, was Mission und Ziele angeht, man sollt's mal ordentlich hinsetzen. Also ich hab so leicht rausgehört, das ist oft wahrscheinlich 'n Aspekt, der sehr stark vernachlässigt wird.
Paula: Schlechte Frust
Dave: dazu. Genau, genau. So, Leute, mach das mal richtig. Gibt's da irgendwas konkret, was Du da empfehlen könntest? So ist es irgendwie gut, wenn man sich als Team mal wirklich zusammensetzt, nur offside geht, komplett ausm Office raus, da wirklich dann 2, 3 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?
Paula: Ja, also auf jeden Fall eine Woche Mallorca, Finca.
Dave: Gar nicht mal so beschäftigt.
Paula: Ja, so. Nee, also ich find schon, wenn man die Möglichkeit hat, sich ein, 2 Tage zu blocken als Team und sich dann mal wirklich mit zu beschäftigen, grade wenn man das zum ersten Mal macht, Mhm. Ist es das wert. Also man kommt da auch gut durch. Man findet eine Mission und Ziele und vielleicht sogar schon 1. Ideen für die Roadmap. Aber es ist natürlich viel Zeit und das überspringt man gern, weil das weil 2 ganze Tage fürn Team oft sehr viel sind, grade wenn man in so Projektteams oder so was sitzt. Da ist die Zeit so eng und der die Deadlines auch so eng, dass man das ungern hergibt, ja. Aber einen Tag würd ich auf jeden Fall empfehlen, dass man sich das nimmt. Und man muss das auch gut vorbereiten. Tipps, wie man das macht, ist schwierig, weil wenn man so im Internet schaut, was gibt's 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 find's wichtig, dass man versucht, die richtigen Fragen zu finden, das aus dem Team herauszubekommen. Also die Mission 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 sone Red Flag, dass da irgendwas nicht stimmt. Also es kann sein, dass das Team da nicht stimmt. So, aber wenn wenn das Team stimmt, dann kriegt man das da raus.
Dave: Oder das Alignment, das da nicht stimmt. So, man hat unterschiedliche Vorstellungen irgendwie, wo man eigentlich hin möchte.
Paula: Genau. Ja, das kann auch sein, dass das ist dann, aber dann ist es vielleicht auch 'n Mismatch von Leuten, die in diesem Team sind.
Dave: Mhm.
Paula: Ne, also wenn wenn man das nicht auf eine Bahn gelenkt bekommt, also da da stimmt auf jeden Fall was anderes nicht. Das ist mein meine meine Erfahrung, sag ich mal, jetzt.
Dennis: Und wie viel spielt da eine strategische Komponente von außen dann eine Rolle? Also es gibt ja wahrscheinlich irgend eine 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, Mhm.
Paula: Die
Dennis: sie jetzt nicht selbst im Team entwickeln. Mhm. Wie spielt das da rein? An welcher Stelle ist das der Input sozusagen?
Paula: Genau, 'n 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 komm ich aus der anderen Richtung. Ich glaube daran, dass man tatsächlich selbstorganisierte Teams schaffen kann, ne. Die schaffen sich nicht von selbst, aber man kann das schaffen. Und wenn man tatsächlich selbstorganisierte Teams hat, hat man eine sogenannte Selbstemergenz, weiß es so auf Deutsch, Emergenz?
Dave: Ich find's sehr schön. Ja. Wirklich lernen es so.
Paula: Ja, so ne. Also das heißt, dass diese Dinge, wenn wenn der 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 das passt. Mhm. Ne, also das ist die Idee von tatsächlicher Selbstorganisation, dass dass man es eben nicht immer injizieren muss.
Dennis: Und würde das Unternehmen das gleiche Modell nutzen?
Paula: Können man kann das auch nutzen, ja.
Dave: War auch mein erster Gedanke. Also tierisch könnte das Unternehmen ja eine Mission haben, Ziele haben und daraus leiten sich wieder Missionen und Ziele für die jeweiligen Unterteams ab.
Paula: Genau, man kann es dann verlinken. Wenn man das auf auf Unternehmensebene macht, hat man, genau, wie gesagt, Missionziele, man hat Unterziele, ist dann oft die, das ist so diese Roadmap Ebene. Die Backlog Ebene wird dann meistens recht dünn, weil man selten tatsächlich hier Workpackages so auf Organisationsebene hat, aber es gibt's schon auch. Ja. Genau. Und die Idee ist, dass wenn man dann eben diese Pyramide auf Organisationsebene hat, man das verlinken kann. Also man schafft dann sozusagen Alignment.
Dave: Gutes Wort.
Paula: Ja. Also ich frag jetzt immer, möcht ich Alignment oder Kohärenz? Also was möcht ich aber in dem Moment krieg ich Mhm. Alleinment, dass ich eben, wenn ich alle Teampyram, die alle auf dieselbe obere Pyramide verweisen, müsst ich theoretisch Alignment bekommen.
Dave: Ah, okay, ja. Das heißt, so würdest Du auch Alignment und Kohärenz unterscheiden.
Paula: Genau, also Kohärenz ist was, wie heißt das, verteiltes, ja. Also das sind Sachen verteilt und es kommt aus sich selbst heraus. Vielleicht geht's auch einher, ich hab's, ja. Also ich könnt ja mal was dazu sagen.
Dave: Philosophieren. Mhm. 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?
Paula: Mhm. Die Pyramide ist deswegen eine Pyramide und kein Trapez, weil das oben hin spitz wird. Und es wird spitz, weil da der Fokus und die Klarheit von Mission und Zielen, wie, jetzt hab ich meine Erfahrung, konvergiert. Es muss dahin konergieren, ja. Also die Mission muss sehr scharf sein, Die Ziele auch, also es sollten auch nicht so viele Ziele sein, ne. Also wer sich 5, 6 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
Dave: Mhm.
Paula: 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. War das jetzt, jetzt wird immer, ich hab's Gefühl, ich werd immer abstrakt Nee,
Dave: aber das ist bei meinem Umfeld.
Dennis: Genau, ich mag es eigentlich ganz gerne, weil es ja irgendwo diese in beide Richtungen geht, ne. Also Du hast eigentlich gesagt, eigentlich startet man ja irgendwo oben, das zu definieren. Und Andererseits finde ich das Bild eigentlich ganz schön, okay, wenn Du dann unten rauskommst und da irgendwo dann, ne, zu viel hast, dass das das andere dann wiederum auch nicht tragen kann, wo es dann auch wieder nach oben babbelt Ja. Und das irgendwie gegenseitig stützen muss. Find ich, find ich dich eigentlich ganz gut.
Dave: Mir ist mir ist son son anderes Bild in den Kopf gekommen, weil Du grad Trapez gesagt hast und ich so mir 'n bisschen vorstellen musste so, wie
Paula: Was ist 'n Trapez? Nein. Ich aber Der
Dennis: schockiert Blick grad, das kann man nicht sehen. Ja, zum Glück machen
Dave: wir Ja, zum Glück waren wir heute ohne Video. Den, den ich geworfen habe. Nee, weil ich mir eigentlich vorgestellt habe, wie diese Pyramide quasi in einem Quader oder in 'nem, also 'n Quader an unendlichen Möglichkeiten drin ist, ja. Und schreibt man
Dennis: ganz kurz 'n Quader?
Dave: Sorry, Quader ist die falsche, ich meinte eigentlich 'n Rechteck einfach nur Quader ist 'n Körper und wir reden über Flächen. 2 d 3
Paula: Ist das aber auch dreidimensional, ist das eingebettet.
Dave: Oh Gott, okay. Nein, wir bleiben 2 d, das kann mein Gehirn gerade noch so irgendwie ab. Genau, wenn man diesen diesen dieses Quader an unendlichen Möglichkeiten hat und dann Ich dachte, Du bist die Pyramide. Entschuldigung, das ist wieder Quader.
Paula: Ja, es
Dennis: muss mal weiter.
Dave: Rechteck. Genau, das Rechteck hat. Stimmt, Das ist
Dennis: jetzt okay,
Dave: wir reden viel zu viel über irgendwelche Körper. Rechts
Paula: ist auch 'n Kreis?
Dave: Das ist auch 'n Kreis. Nee, und dann quasi die unendlichen Möglichkeiten nach links und rechts hat, dann sone 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 viel Dingen ja und ich glaub, dieses ein, das Problem, das wir eingangs hatten, was Du meintest, das Backlog ist riesig. Mhm. Einfach aufgrund von Dingen, wo man gesagt hat so, ja, sagen wir dazu jetzt, ja oder nein? Und ich glaube, das ist hoffentlich eine 'n schönes Bild.
Paula: Ich find's superschön, ja. Es gefällt mir sehr gut, ja. Weil dieses eine gute Mission und Ziele finden heißt auch, sehr viel Nein sagen, ne. Das ist 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. Mhm. Es gibt oft Sachen, wo man sagt, das ist jetzt aber auch wirklich wichtig, aber es geht halt nicht.
Dennis: 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?
Paula: Genau, im Idealfall ist das so. Also wir haben begrenzt Platz in unserem Kopf. Ich glaube, irgendwie 8 Dinge kann man gleichzeitig im Kopf haben.
Dennis: Ich glaub, Safe Date mehr.
Dave: Ah ja, ja genau. Also ich, 7 ist sone magische Zahl bei Menschen, hab ich hier gefühlt. Es gibt die 7 Weltmeere, obwohl's ja potenziell mehr Meere gibt. Es gibt die 7 Weltwunder, obwohl hier allein schon 3 Weltwunder sitzen so. Also genau, deswegen, es könnte ja auch wirklich, also, also 7 ist, glaub ich, sone magische Zahl.
Paula: Okay, lass 7 sein. 7. 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 den diesen Mental Load irgendwie losbekommen, 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 hab ich erst mal Platz geschaffen für die anderen Sachen. So. Und natürlich muss ich mich im Alltag immer mal wieder damit beschäftigen, wie ich schon gesagt hab, man muss es immer wieder checken, passt es immer noch und so weiter, aber ich muss es halt nicht jeden Tag machen. Mhm. Und ich kann dann auch einfach mal an Tagen sagen, wir haben's besprochen, ich weiß, was jetzt zu tun ist. Mhm. So, ich kann mich jetzt auf den nächsten Schritt konzentrieren und nicht immer auf alles andere, was noch auch noch danach kommen müsste.
Dave: Mhm. Ich glaub, also ich glaub, das hilft dem Team insgesamt halt einfach supergut 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 man damit argumentieren, nee, unsere Ziele sind eigentlich so und so. Ja. Das zahlt gar nicht drauf ein. Warum sollten wir das priorisieren an der Stelle?
Paula: Genau.
Dave: Also eigentlich eine gute Maßnahme.
Paula: Ist 'n gutes Kommunikationsmittel. Ich kann damit einfach auch nach außen gehen, sagen, das ist das, worauf wir uns verständigt haben.
Dennis: Mhm. Und
Paula: darauf beruf ich mich. So und wenn sich Dinge so ändern, dass es eben nicht anders geht, dann muss man's eben wieder neu verhandeln, das ist okay. Aber ich hab immer die Möglichkeit, damit erst mal 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 sogenannter High Performer bezeichnet, ne. Also das sind, man hat, es sind nicht die, die immer zu einem ja sagen und alles wegarbeiten. Es sind die, die wirklich klare Grenzen haben und sich auch an Prozesse halten. So, eine Beobachtung.
Dave: Spannender Take.
Paula: Ja. Es sind Leute, die auch auf ihre Ressourcen achten, ne. Könnt ihr auch noch mal überlegen. Also es gibt sicherlich auch Leute, die High Performer sind und die ganze Zeit super für arbeiten. Das Denn das ist gerade 'n
Dave: bisschen überfordert mit dem Überlegen.
Dennis: Ja, das also, finde ich superspannend und aber deswegen haben wir beide auch, glaub ich, gezögert, weil man erst mal dann natürlich darüber nachdenken muss, ne. Erstens, also was in welchem Setting ist, was man sonst kennt man und versucht da 'n bisschen drauf zu reflektieren. Deswegen ist grade die Antwort nicht so schnell gekommen. Aber ja, ist spannend, spannendes Ding.
Dave: Ich glaub, ja, weil ich auch spontan an Leute gedacht habe, wo ich sagen würde, das sind High Performer, aber ich glaub, die rattern auch sehr viel weg in der Breite. Also das ist glaube ich auch das Interessante. Und ich glaub bei dem, KC, den Du grade nennen hast, also ich würd das nicht per se ablehnen, aber ich glaube, da müssen wir trotzdem überlegen, weil ich glaub, ich ich glaub, es ist vielleicht son Mindset, das generell 'n bisschen in uns verankert ist so irgendwie, ja, wenn man viel macht, dann dann Das ist gut. Genau, das ist gut. Aber es ist ja aber, also wenn man viel macht, was nutzlos ist. Ja. So. Also warum sollte es dann besser sein? Also ein spannender Gedanke.
Paula: Exakt. Also ich sag das vor allem deswegen, also es gibt mit Sicherheit auch Leute, die superviel arbeiten und auch sehr, sehr gut Leistungen da abliefern. Aber ich will das 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.
Dave: Mhm.
Paula: Mhm. Das also das ist nicht die Erfahrung, die ich gemacht hab. Ja. Das sind andere Sachen, die sich negativ darauf auswirken. Ja.
Dave: Ja. Du sahst so grübeln aus.
Dennis: Ja, also warum ich grübeln haben wir ja grad schon erklärt.
Dave: Nee, hab
Dennis: ich keine Frage stellen.
Dave: Soll ich eine Frage stellen?
Dennis: Oder Du hast Du grade, Du Du guckst sehr konzentriert heute in dein Handy die ganze Zeit.
Dave: Also Ja, ich hab hier megaviele Notizen. Ich nehm die Aufgabe sehr ernst, quasi das zu moderieren. Parten reinbringen. Genau. Und Du bringst nicht mehr aus diesen Parten raus, was vollkommen okay ist in so unserer Podcast.
Dennis: Aber das ist auch eine Gefahr, sone Struktur zu haben. Dann denkst Du, oh, jetzt müssen wir aber darüber reden.
Dave: Nee, ich will sie einfach nur in die grade Bahn lenken, so deswegen. Ich hab's schon sehr oft ausbrechen lassen. Genau.
Dennis: Okay, soll
Dave: ich ausbrechen? Brechen wir kurz aus, komm. 1,
Dennis: wie siehst Du, also es gibt ja durchaus auch andere Systeme
Dave: Ja, machen wir's nicht.
Dennis: Die versuchen darauf einzugehen, ne, son bisschen eine Organisation zu strukturieren. Ich glaube, 1 der ganz großen ist irgendwie, was Google mal gemacht hat mit OKRs, was ja irgendwie objective und key results sind, das aber auch son bisschen. Es babbelt von oben bisschen was runter und von der anderen Seite es babbelt von unten bisschen was hoch und jeder hat so seine, ne, definiert, 'n bisschen klarer, was sind denn eigentlich unsere Ziele auch? Und da noch stärker vielleicht auch, wie können wir sie messen? Ich glaub, das ist nicht unbedingt jetzt in in dem Modell. Haben wir den Namen für dieses Modell schon genannt?
Paula: Das ist das VTA Model, das Vision Interact Model.
Dave: Wish Interact, ja.
Dennis: Haben wir nicht Gut, erklär
Dave: mal gut. Aber gut,
Dennis: gut moderiert denn das. Danke. Wie siehst Du da die Abgrenzung? Mhm. Hast Du, 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 ist eigentlich was noch anderes?
Paula: 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. Mhm. Wenn Du möchtest. Mhm. Meine Meinung generell dazu ist, dass man immer schauen sollte, was wirklich zum eigenen Team passt oder zum eigenen Setting passt. Ich würde, glaub ich, immer davon abraten, einfach irgend 'n Framework zu nehmen und das umzusetzen. Das mag zufällig passen, aber ich glaub, in den meisten Fällen schafft das auch immer viel Reibung. Also es ist ja irgendwie immer, ich nehm eine Schablone für irgendwas und leg das über was drüber und hoffe, dass dann irgendwie die Menschen da reinpassen. So, und deswegen würd ich immer dazu raten, sich genau anzuschauen, was machen diese Frameworks? Was macht die aus? Und was brauch ich davon wirklich? Also generell jetzt von OKR abgesehen würd ich das zu jedem Framework sagen. Und ich glaub, der Trend geht auch so in dieser ganzen agilen Organisationsentwicklung, geht auch mehr dazu, dass man eben nicht mehr zu diesen fertigen Frameworks sinniert, sondern dass man wirklich sagt, schaut, dass ihr euch das maßschneidert. Dafür gibt's ja auch Leute wie mich, die in Firmen arbeiten, die das machen. Mhm.
Dave: Also. Mhm. Ja, allein also allein von der Definition hätte ich 'n bisschen gesagt, dass das sehr gut sogar synergien kann. Also ich find dieses Vision to Act Modell, was Du ja mit der Pyramide meist, worauf wir gleich noch mal näher eingehen werden, wir haben 'n paar Ebenen ausgelassen. Aber dass wir quasi bei OKR, was ja Objectives, Result Result Result sind, ich glaub, da ist es eher son bisschen, man kann die Ziele da rausnehmen
Paula: Mhm.
Dave: 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.
Paula: Mhm. Wenn man diese Messbarkeit möchte.
Dave: Genau, wenn man sie möchte, Genau, man
Paula: fragen, ob man das unbedingt braucht. Mhm. Ja, also wir tendieren dazu immer, alles so messbar zu machen, ja. 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 dieses soziotechnologischen 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? Es ist immer notwendig. Deswegen meinte ich auch zu 'nem Ziel, also man kann Smart ghost machen, also sehr messbare Ziele machen. Oder man hat eher so, ich hab's directional Priorities genannt, also gibt es eher eine Richtung vor, aber dann brauch ich irgendwie 'n gemeinsames Verständnis von der Definition of dann. 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.
Dave: Ja. Aber find ich interessant, weil eine, also wenn man jetzt auf das Produkt achtet, würd ich sagen, braucht man ja schon eine gewisse Messbarkeit, Erfolg festzulegen. Mhm. Also beispielsweise, keine Ahnung, bei einem Produkt ist ist einfach, man verkauft es, dann will man ja sagen, wir wollen's häufiger verkaufen so und wenn Leute irgendwie 'n Abo haben, dass die Leute länger bleiben oder mehr Leute 'n Abo abschließen über längere Zeit. Also find ich, ist dann, glaub ich, da eine Messbarkeit schon durchaus relevant. Ja. Und deswegen aber, Du hast ja dieses soziologische irgendwie Soziotechnologisch. Soziotechnologisch. Kannst Du darauf noch mal näher eingehen, weil das würd ich interessant finden, also was man da irgendwie, worauf man da achtet.
Paula: Also im Prinzip geht's da, dass es allgemein beschreibt, das eine Richtung, in die man sich so überlegen kann, wie die Sachen aussehen. Und ich, mein Gefühl ist, dass grade mit diesem AI in der Nutzung zur Entwicklung von Software das aufgekommen ist, dass man sich wirklich fragt, was ist denn jetzt der der 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.
Dennis: Mhm.
Paula: Punkt. So, und dadurch ist diese Abgrenzung überhaupt zu suchen. Genau, und da gibt's natürlich verschiedenste Themen, mit denen man sich da beschäftigen kann. Also arbeiten wir mit AI oder die AI mit uns oder ne, also solche Sachen. Aber die Frage ist zum Beispiel jetzt auch in dem Fall, wenn ich Ziele mach, die messbar sind, was jetzt bei sonem Produkt irgendwie Sinn ergibt, ne, ich möchte wissen, wie viele Abonnenten ich hab, ist es gut. Wenn ich jetzt aber Ziele hab, die messbar sind, die sich wirklich eher auf das Team beziehen, dann ist das eben nicht an einem Produkt gemessen, sondern an Menschen gemessen und das macht was mit Menschen. Und das, die Frage ist immer, macht es das mit Menschen, was es soll oder macht es was anderes? Hast Du's unter Kontrolle?
Dave: Mhm. Ja.
Paula: Und wie viel können wir noch auf unser Bauchgefühl hören, wenn wir eigentlich nur noch Daten angucken? Also ich bin nicht gegen das Messen, das möcht ich damit nicht sagen, aber ich ich mein nur, es muss nicht immer alles messbar sein.
Dave: Mhm. Ja, ist spannend, weil ich, also ich glaub, aus 'ner sehr datengetriebenen Rolle herauskomme und alles auch immer so, was weiß ich.
Dennis: Ich weiß nicht ausreden.
Dave: Ja, genau. Und das das durchaus 'n Aspekt bei uns ist, ne, also weil wir ja auch Spiele machen und dann auf der einen Seite so haben wir einfach so diese harten Fakten so, das sagen die Zahlen, das ist so das, was sie quantifiziert haben. Und gleichzeitig gibt's ja auch qualitatives Feedback, ne. Leute schreiben uns, Leute äußern ihren Frust so. Und da sind natürlich immer diese Gegensätze so, hey, das Produkt performt rein zahlentechnisch richtig gut. Wir kriegen aber jetzt grade irgendwie 500 Nachrichten von Leuten, die das komplett hassen so. Aber eigentlich funktioniert es auch nicht. Die teilen
Dennis: die Liebe mit uns.
Dave: Sie teilen die Liebe mit uns, genau.
Paula: Genau. Und das
Dave: ist aber auch schon 'n interessanter Aspekt, worauf hört man und Genau,
Paula: ist auch son 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, ne. Also dieser, alles, was ich messe, sind ja irgendwie Abbildungen von was sehr abstrakten, vierdimensionalen auf irgendwas eine Zahl. Ist ein ein d. Ist eine krasse Abbildung. Ja. Du lässt superviel weg, indem Du das machst.
Dennis: Und wo ich dir noch kurz wieder, 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 so was, ne, was er da irgendwie, glaub ich,
Dave: auch in menschlicher Ebene noch
Dennis: alles klar. Ein sehr wichtiger Teil ist, ne, den's jetzt auch grade ging, so, ne, wie wie was macht das dann mit den Menschen? Keine Ahnung, was. Weil das haben wir ja zum Beispiel gar nicht. Also es gibt, ne, wir haben keinen Auftraggeber, wir haben nur irgendwie uns selbst. Das heißt, das ist son sehr freier Raum, in dem man irgendwie agiert. Wo man sich natürlich auch manchmal fragt, okay, son bisschen wär irgendwie ja ganz schön, ne, zu wissen, wenn Du irgendwelche Entscheidungen triffst, wie Du was strukturierst und wie, irgendwie das zu wissen. Und das basiert halt aktuell komplett, würde ich sagen, aufm Bauchgefühl, Ohne
Paula: ob man
Dave: das dann
Dennis: zu sagen, so wie wie läuft die Entwicklung bei uns.
Dave: Ja, gut gefühlt auch, das funktioniert in einem Team gut, in dem anderen auch. Ja, okay, da muss es für alle Teams gleich gut funktionieren und jedes Team hat wahrscheinlich andere Ansprüche, aber wir machen das vielleicht grad nicht so individuell.
Dennis: Ja, das ist 'n anderer Podcast, aber find finde ich auch ganz cool, dass es ist.
Dave: Ich mein Neues.
Paula: Ne, also dafür gibt's auch eben so Ansätze, dass man sagt, ah ja, diese DevEx Geschichte, man soll eben Umfragen machen, dass man da irgendwie messbare Skalen kriegt und so weiter, dass man irgendwie Verbesserung feststellen kann. Ja. Also ist auch doof, wenn man gar nichts misst, weil man dann, ja, wie gut ist dein Bauchgefühl?
Dennis: Meinst Du ganz gut?
Dave: Ja, super. Na, selbstbewusst. Gut, ich würde an der Stelle aber noch mal Auf
Dennis: die Ebene eingehen. Auf die Ebene
Dave: eingehen. Genau, ganz genau. Wir waren ja weiterhin schon
Dennis: geführt, dass Du gerne noch die 3. Ebene erst mal klären möchtest. Ja, vielleicht sogar auch die 4. Mal gucken. Wow.
Dave: Genau, es geht, wir haben über die VTA Vision zur Ek Pyramide geredet. Zwischenfrage.
Dennis: Ist das,
Dave: Entschuldigung. Ja, okay, nee, darfst Du.
Dennis: Ist das 'n ist das Wording von dir,
Paula: Paula? Okay.
Dave: Also das ist nicht,
Paula: weißt Du,
Dennis: was soll da draus sagen, sondern Nee,
Paula: ich muss es vielleicht auch mal irgendwo veröffentlichen auf irgend 'nem Blog. Ich wollt
Dennis: grad sagen, müssen wir noch mal, damit wir das jetzt, damit das 'n Ding wird.
Paula: Ja, 'n bisschen. Ja, ich hab meinen Auftrag verstreut jetzt hier.
Dave: Nee, nee, nee,
Paula: nee, nee, nee, nee, nee, nee, nee, nee,
Dennis: nee, nee, nee, nee, nee,
Dave: nee, nee, nee, nee, nee, nee, nee, nee, nee, nee, nee, nee, wir haben über die Mission und Ziele geredet, was das bringt. Uns oft hilft, nein zu sagen. Da gibt's jetzt aber die 3. Ebene, das ist die Roadmap. Mhm. Genau. Da ist vielleicht wichtig so, 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?
Paula: Mhm. Das kannst Du mir wahrscheinlich sogar noch besser sagen.
Dennis: Aber Aber ich bin ganz kurz verwirrt.
Dave: Warte mal. Mission, Ziele, Roadmap.
Dennis: Und dann?
Dave: Dann ist das Backlog den letzten Ach, Backlog.
Paula: Und das ist das Backlog. All das, was wir besprechen, müssen wir wirklich machen. Das ist wichtig. Ja,
Dennis: genau. Gut.
Paula: Okay. Wir
Dave: wollen, genau,
Dennis: weiter. Ja.
Paula: Ja. Ja. Die Roadmap, oh Gott, das war ausm. Für mich ist die Roadmap, also es ist natürlich der Weg, wie wir da hinkommen. Also wir brauchen irgendwie die Bausteine, was aufzubauen, diese Ziele zu erreichen. Das heißt, wir müssen identifizieren, was was braucht es? Was eine Roadmap für mich auch ist, ist 'n starkes Kommunikationsmittel, weil diese Bausteine zu finden, das mag das eine sein, sie aber zu priorisieren in 'nem auf 'nem Zeitstrahl, ist noch mal was anderes. Also man muss irgendwie in Interaktion mit anderen Menschen treten in der Firma, Stakeholdern, weiß nicht, hängt vom Team ab. Mhm. Also das ist das eine. Und was ich auch immer empfehlen würde, ist, genau zu überlegen, wie diese Roadmap eigentlich aussieht. Ich glaub, man ist immer sehr schnell daran zu sagen, ja, Zeitstrahl und jetzt kommen da irgendwelche Lanes, irgendwelche Sachen, die wir da machen. Ja. Und das So
Dave: bin ich.
Paula: Ja. Ja, also es ist ja auch, man hat dann aber dann hat dann wieder diese Divergenz so schnell, ne, dass man irgendwie sagt, ah ja, dann pack ich das jetzt alles da rein.
Dave: Und es
Paula: wird irgendwie abgearbeitet, aber man muss sich genau überlegen, welche Kapazitäten hab ich eigentlich? Also ich hab eine bestimmte Zeit, die ich arbeiten kann und die muss sich einteilen in bestimmte Fragmente, die irgendwie da sind. Ne, also wenn ich jetzt wie in meinem Fall mit 'nem DevOps Team arbeite, die müssen eben bestimmte Zeit allokieren, Support machen zu können. Wenn wir 'n haben, wenn irgend eine Pipeline down ist, müssen die wie die Feuerwehr einspringen und das irgendwie hinbekommen. Mhm. Na, da können die nicht bis oben hin ausgeplant sein, wir müssen da irgendwie Zeit für haben. So. Und das muss man vorher mit rein designen. Also welch, wie viel Zeit brauch ich für was? Mhm. Weil das bedeutet auch für deinen Backlog wird das eben Raum einnehmen. Du kannst da nicht mehr so viel in deinen Backlog reinschieben, weil Du ja Zeit für andere Sachen übrig lassen musst.
Dave: Mhm. Ah okay, das heißt also, nur das richtig zu verstehen, das heißt, Du würdest auch einordnen in auf der Vertikalen hast Du quasi diese maximale zeitliche Auslastung, die wir haben können. Und auf der Horizontale halt quasi, was wann kommt, so wird es strukturieren.
Paula: In welcher Reihenfolge wir jetzt, sag ich mal.
Dave: Genau, Reihenfolge. Ja, genau. Ah.
Paula: Und was auch manchmal hilft, ach nee, wir sind noch nicht bei Backlog, aber was manchmal hilft war, dass also Roadmap und Backlog Kannst ja
Dave: auch den perfekten Übergang machen.
Paula: Genau. Also Mission und Ziele hängen son bisschen zusammen wie Roadmap und Backlog. Mhm. Ne, also weil man mischt das 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, in den Backlog nicht so in diesem linearen Jarra 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 son Stück Torte aus deiner, aus diesem Kreis aus. Und das, was dann noch übrig übrig bleibt, ist dann das, was Du eigentlich für deine Mission und für deine Ziele hast, ne. Das sind die Kapazitäten dafür. Und mehr passt da nicht rein. Mhm. So. Und dann überleg dir, wie viele Lanees Du da offen haben kannst, Wie viele Epics Du gleichzeitig in dem Team bearbeitet bekommst.
Dave: Ja. Ja, find ich gut, weil man dann gezwungen ist in dem Kontext und dem Rahmen halt, sich auch im Vorfeld Gedanken zu machen so, okay, ist dafür Zeit oder nicht? Mhm. Also ja.
Paula: Und es gibt eben Sachen, die nicht verhandelbar sind, ne. Das man verhandelt die trotzdem oft. Sind halt nicht verhandelbar.
Dave: Mhm. Beispielsweise Supportthemen, Bankfixist oder so was. Genau. Mhm.
Paula: Und wenn man, also jetzt Add on plus, ne, 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 Tortendiagramm, das wär doch schön.
Dennis: Cool. Wie ist es konkret, in welcher Form bringt ihr das unter? Also
Dave: Lag ist komplett vollständig?
Paula: Ja, voll konkret. Danke.
Dennis: Nein, also Schriftlich. Du hast ja gesagt, ne, so hast dem Ganzen jetzt 'n Namen gegeben. Wie wie wird es denn implementiert? Also hält man die Ziele irgendwie schriftlich fest? Ist da eine Präsentation? Also die ist einfach so die, wie macht ihr das im Moment, das zu leben? Was sind also was sind Tools, die ihr nutzt, sind das, genau. Du hast irgendwie grade von Giira Tickets oder Boards geredet oder wie auch immer. Gibt's da schon irgendwas, was Du sagen würdest? Oder sagst Du, die theoretische Ebene reicht erst mal?
Paula: Na ja, die reicht natürlich nicht. Aber grad eben sind wir da noch bei der bei der Anarchivphase. Also es ist sinnvoll, das aufzuschreiben. Mit meinem Team hab ich viele auf Figma Boards stehen.
Dave: Mhm.
Paula: Es ist visuell, ne, es ist für alle zugänglich, es ist einfach. Also ich würd immer das nehmen, was einfach ist und was reicht. Für uns reicht das grad. Ansonsten, die Tickets sind natürlich im Jura. Okay. Es ist wichtig, dass man das kommuniziert. Das ist nichts, was man geheim hält für sich. Und wenn mal jemand fragt, dann gibt man vielleicht 'n bisschen was Preis. Mhm. Man muss damit rausgehen, man muss irgendwie in Kommunikation traden, den Leuten sagen, das haben wir vor. Das das ist das ist das, woran wir uns festhalten. Mhm. Ja. So, das passiert jetzt noch nicht so viel, aber das theoretisch, wenn's da Konflikte gibt, weil irgendwie Sachen nicht zusammenpassen, dass man eben den Raum schafft, das überhaupt aufzudecken. Ja. Ja, das ist auch eine Art von Messbarkeit. Okay.
Dennis: Also ist das eigentlich grundsätzlich superindividuell, was das Unternehmen angeht, wie da die Prozessanstrukturen sowieso sind. Und man versucht es dann einfach daran zu allein und die Kommunikations- und sonstigen Mittel zu nutzen, die auch sonst genutzt
Paula: sind. Genau. Man fängt jetzt an der einen Stelle an und dann schaut man, wie man weiterkommt.
Dennis: Okay.
Paula: War das war das die die Antwort?
Dennis: Ja. Ja, also ich, keine Ahnung, hätte auch sein können, ich hab hier son Vision to Act App gemalt
Dave: geholt Das kommt später. Oh.
Paula: Es kommt. Also das Buch, das Tool, das kommt alles später, ja.
Dave: Traust Du grad 'n Buch?
Paula: Nee, noch nicht.
Dave: Ah, okay.
Paula: Ich mach das, es war Noch nicht mal Blogeintra. Nee, ich mach gleich 'n Buch draus. Ja.
Dave: Ja. Ja, mein mein mein eine vorletzte Folge, da hat die die Gästin auf jeden Fall 'n Buch geschrieben. Das fand ich sehr interessant.
Paula: Ja, vielleicht kommt das ja noch. Da komm ich dann nur noch Hättest
Dennis: Du denn hättest Du denn schon 'n Blog, wo Du den Beitrag veröffentlichen kannst?
Paula: Nee, noch nicht.
Dennis: Okay. Wär ja auch Teil davon. Na gut.
Paula: Ja, das ist also
Dave: Oh, das wär aber eigentlich sehr gut.
Paula: Ich mach jetzt eine Mission. Okay, meine Mission ist, das Veröffentlichen. Ziel.
Dave: Ist das nicht 'n Ziel?
Paula: Block finden, Text schreiben.
Dave: Sehr schön. 'N Aspekt Natürlich, aber das würde jetzt eher
Dennis: eher den Druck, die die Drucknummer dann wieder erhöhen und nicht, dass dass man die Sachen nicht parallel machen soll. Ist eigentlich sehr kontraditiv, das wär jetzt zu tun. Ich wollt grad vorschlagen, na ja, wir können ja so lange warten mit der Veröffentlichung und mehr Folge, bis Du diesen Blogartikel hast, damit
Dave: Du das direkt damit Du's
Paula: direkt draußen
Dennis: Das ist gleich verlinken. Okay. Ja, verlinken kann. Aber dann Weißt Du wie lang
Paula: wie lang eure Vorlaufzeiten sind?
Dave: Bis nächste Woche ist 20.
Dennis: Nein. Also wenn's schon was gäbe, dann verlinken wir das natürlich gerne in den Shownotes.
Paula: Ja, ich kann kann ja mal schauen. Also diesen Monat schafft's Google
Dave: Learning kann
Dennis: man, gibt's
Paula: doch. So
Dennis: Google Ads?
Dave: Ja, ja, ja.
Dennis: Genau. Paula Ostmann, Vision to Act und dann kommt das direkt reingespült, so weit er 1.
Dave: Ja. Genau, ein Aspekt, auf den ich noch eingebwollte, weil wir den vorhin kurz angeschnitten haben, ist natürlich Stichwort Agilität. Mhm. Weil es gibt ja also, man ist ja nicht im luftleeren Raum mit seinem Produkt und seinem Team, so. Es gibt ja viele Einflussfaktoren, ne. Beispielsweise etwas, was sich im Team verändert, strukturell, ne, 'n Teammitglied verlässt das Team. Gleichzeitig gibt's ja externe Faktoren wie beispielsweise, Du hast gesagt, die arbeitet mit Banken zusammen, so, da können ja neue Auflagen irgendwo entstehen, was auch Datenschutzkonformität und so was angeht, ne. Gleichzeitig gibt's 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 'n bisschen shiften dadurch. Und jetzt ist der richtige Zeitpunkt dafür. Wir können nicht warten so. Wie wie reagiert dieses Modell generell so bisschen auf so externe Faktoren und wie bleibt man damit agil?
Paula: Mhm. Oh, ist jetzt das hier auf einmal? Also erst mal, wie reagiert das Modell darauf? Wenn ich eine Veränderung habe, dann muss ich schauen, passt das zu dem, was ich mir vorher überlegt hab? Also ich hab eine Veränderung, das macht was mit meinem Backlog, das macht was mit meiner Roadmap. Also irgendwo findet diese Veränderung statt. Sag mal, ich hab eine Veränderung in meiner Roadmap, weil neuer Kunde und es müssen jetzt irgendwie ganz neue Sachen da irgendwie rein. So. Und dann muss ich schauen, passt das zu meinen Zielen? Passt es zu meinen Zielen super? Wenn's nicht passt, ich kann's aber auch nicht, also wenn's nicht passt, könnt ich jetzt sagen, nee, dann kann ich's nicht machen. Oder ich stell fest, ich kann's nicht ändern, weil wir haben jetzt noch mal den neuen Kunden und ich kann jetzt nicht aber nein
Dave: sagen.
Paula: Klar. Ja, das heißt, da 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. Genau. Und dann bleib 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.
Dave: Mhm. Also genau, also es ist kein festes Konstrukt, sondern man muss selbst immer regelmäßig mit sich ins Griechchen, passt das noch? Ist das grad die aktuelle Genau.
Paula: Und jetzt zu dem Agierteil, deswegen hab ich das grad rausgelassen. Mhm. Das find ich dahingehend ganz spannend. Was heißt denn Agile für dich? Das frag ich immer alle. Ich bin immer gespannt auf dich.
Dave: Ja, die Frage lad ich an meinen Co Host Dennis weiter. Ich würd, nein, also ich kann das sehr gerne beantworten. Natürlich. 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ürd ich sagen.
Paula: Okay, also das eigentliche Wort agil sozusagen. Nicht
Dave: Das eigentliche wird genau.
Dennis: Es gibt
Paula: der Agile Groß agier und Klein, ja.
Dave: Oh, wirklich?
Paula: Ja, das so so wird das oft transkripte.
Dave: Das heißt, glaub ich, auch beweglich einfach, oder? Also wortwörtlich übersetzt beweglich. Ja. Dennis, wolltest Du was sagen? Dein Also
Dennis: für mich ist maximal wenig Prozesse.
Dave: Oh. Okay.
Dennis: Oh, das spielt
Dave: wahrscheinlich Ja, ich weiß nicht.
Dennis: Scheint wahrscheinlich maximal überzeugt, diese Antwort. Eine Antwort war schon.
Paula: Nee, also ist nicht, also 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 1 davon ist Einfachheit und ich glaub, das wird auch oft vergessen. Von daher ist maximal wenig Prozesse, glaub ich, dahingehend ganz gut,
Dennis: ne.
Paula: Also man sagt nur so viel, wie eben notwendig ist, deswegen musst ich kurz drüber nachdenken.
Dennis: Mhm. Danke.
Paula: Dieses auf Veränderung reagieren find ich an sich auch gut. Für mich heißt es, also deswegen hab ich gefragt, weil ich nicht so einfach sagen kann, was ist agil in meiner Pyramide da zu tun hat. Für mich heißt agil sein, das ist einmal kontinuierliche Verbesserung, ne. Also dass man die ganze Zeit schaut, was ist dieser dieser Lernzyklus? Also ich bin in 'nem Zustand, ich beobachte, was ist mein Zustand, was könnt ich besser machen? Ich setz es an, ich mach 'n Experiment und schau, in welchem Zustand ich rauskommen. Und im besten Fall ist es eine Spirale, die nach oben geht, das heißt, ich werde immer besser. Und das wend ich an, nicht nur auf die Art, wie ich arbeite, sondern auch auf die Strukturen, mit denen ich arbeite. Also agil heißt eben nicht, ich ich mach, was ich will, ich reagier irgendwie superschnell auf alles, sondern ich hab 'n recht klares, 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 reviewt. 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 eben in maximaler Leistungsform uns befinden. Das war jetzt nicht so wie Einsatz, aber genau.
Dave: Oder ein Wort.
Dennis: Das heißt bisschen besser.
Paula: Das heißt 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 gut rein, weil ich eben Feedbackzyklen habe, ne. Also ich hab Möglichkeiten, Sachen immer wieder zu verbessern und anzupassen. Gleichzeitig hab ich aber 'n klaren Rahmen, in dem ich mich bewege. Also ich hab mir einmal überlegt, was was möcht ich, wo möcht ich hin? Und in diesem Rahmen beweg ich mich dann. Mhm. So. Und es ist aber auch minimal, ist ganz einfach, ja. Möglichst wenig Struktur, ne.
Dave: Cool. Sehr cool. Mhm. Jetzt hab ich's
Paula: totgeräte zu tun. Nee.
Dennis: Du noch Fragen? Nee.
Dave: Ja klar. Genau. Weil ist auch 'n Aspekt, den wir Ich hab das schon im Blick. Nee, ja, genau.
Paula: Was hast Du im Blick?
Dennis: Die Uhrzeit.
Paula: Die Uhrzeit.
Dave: Die Uhrzeit. Die Uhrzeit.
Paula: Die Uhrzeit.
Dave: Die Uhrzeit. Die Uhrzeit. Genau.
Dennis: Ihr habt, im Vorgespräch hab ich gesagt, Voller, 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. Auch noch heute können wir uns wieder sehr gut unterhalten, aber ist doch alles gut. Wir sind noch
Dave: Genau, wir sind komplett Track.
Dennis: Genauso wie es Du, Dave, Dave dir das ausgedacht Richtig. Ja.
Dave: Wir sind zeitlich genau da, wo ich gedacht habe, wo wir bei Minute 52 sind. Ja. 52. Ja, ist krass, ne?
Paula: Halt, ich
Dave: find's die Zeit für
Paula: die Ja, das kenn man nicht.
Dave: Wenn man Spaß hat.
Paula: Ja. War's so schön.
Dave: Genau. Ich würd ich würd ich würd bisschen übergehen zu soner Art Bewertung oder Empfehlung, sone. 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 für für Leute wahrscheinlich noch mal wichtig zu hören, aus deiner Sicht, was ist für dich so der größte Vorteil dieses Modells? Inwiefern enabled des Teams richtig? Mhm.
Paula: Der größte Vorteil ist, wenn ich mich über, wenn ich zu viel Arbeit mich rum hab und ich seh nicht durch, was 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 wir's, dass man das gemeinsam macht. Also man kann als Team gemeinsam da Ordnung und Struktur reinbringen, an der man sich entlanghangeln kann.
Dennis: Damit man
Paula: eben nicht immer wieder verloren ist und nicht immer wieder nach 'nem halben oder 'nem Jahr dasteht und sich fragt, jetzt haben wir denn unsere Ziele schon wieder nicht erreicht?
Dave: Mhm. Genau. Das heißt, auf der Kehrseite, wenn man das Gefühl hat so, hey, in meinem Team ist alles supergeordnet, superstrukturiert so, da lohnt es sich jetzt nicht, das einfach noch mal drauf zu wälzen das System.
Paula: Habt ihr solche Teams, wo man sagt, hey, es läuft, also es ist ja Wahnsinn, also ihr seid alles supersortiert, wow. Nee, also ich mein, wenn das grad gut läuft, muss man jetzt natürlich kein, nicht noch mal alles aufwühlen. Das kann natürlich auch Vorteile bringen, dass man's noch mal 'n bisschen ordnet und so weiter. Aber ja klar, wenn man jetzt grad happy und zufrieden ist, dann ist gut. Man sollte immer das machen, was man selber braucht. Sind wir wieder bei der Einfachheit, ja. Also man macht das, was grade gebraucht wird. Ja.
Dave: Aber ich glaub
Dennis: Möglichst wenig.
Dave: Möglichst wenig. Ich hab, ich glaub, aber das ist halt sehr schwierig zu beurteilen. Also ich glaub grad für irgendwie sehr neue frischeteams auch so, irgendwie zu beurteilen so, was brauchen wir grade? Was fehlt uns? So, was was könnte uns helfen? Mhm. Ist, glaub ich, gar nicht so einfach, das dann zu erkennen. Ja. Und dann
Paula: Aber dann fängt man einfach wieder von vorne an und sagt, was, wo wollen wir denn hin? Was brauchen wir denn da?
Dave: Ah. Was sind wir bei dem Modell?
Paula: Ja, was meint er da? Ja.
Dennis: Und man lernt ja auch damit, ne, den Umgang damit. Mhm.
Dave: Also ich
Dennis: finde, das ist ja auch irgendwie was, was man sieht, in in Teams sehr unterschiedlich sind und je nachdem, wie weit ein Team ist in meiner Vorstellung, desto weniger braucht es auch vielleicht davon, ne, weil es halt vieles automatisiert macht. Und je, ja, frischer oder unorganisierter oder unklarer oder so weiter, desto mehr helfen auch dann solche Tools, Ja. Genau das reinzubringen. So. Ja. Ja. Wo's eventuell dann sogar Teams ausbremsen könnte im ersten
Dave: Fall so, wenn irgendwie so alles klar ist und so alles, komm, lass mal schnell pushen oder so. Wenn man das dann natürlich dann zu sehr irgendwie Strukturen versucht, reinzubringen, dass es dann einen doch erst mal hemmt. Genau, man muss auch keinen Stau Strukturen versucht reinzubringen, dass es dann einen doch erst mal hemmt.
Paula: Genau. Man muss auch keinen Staub aufwirbeln, wo grad alles gut ist.
Dave: Ja. Ja. Ja. Dennis? Ja. Hast Du noch eine Frage?
Dennis: Keine inhaltliche?
Dave: Eine persönliche?
Dennis: Ja. Oder eine. Nee. Dürfen dürfen die Leute dich kontaktieren, Paula, wenn sie Fragen oder Anregungen zu diesem Modell haben?
Paula: Natürlich, sehr gern.
Dennis: Okay. Und das machen Sie über Den Login oder
Paula: Den Blog, ja. Auf LinkedIn, ja. Einfach auf LinkedIn.
Dennis: LinkedIn, okay.
Paula: Paula Ostmann. Einfach schreibt mir. Sehr gern.
Dennis: Gut.
Paula: Ich red gern drüber.
Dennis: Sehr gut.
Dave: Sehr cool. Dann haben, willst Du
Dennis: Na, ich hab nur dich angerufen, Frauke.
Dave: Genau. Dann wie immer am Ende unseres gibt's eine Frage, die ich sehr gerne stelle. Und zwar, wenn man jetzt quasi die die letzten 50 Minuten nicht so toll zugehört hat und sich eine Sache rausnehmen sollte, was besonders wichtig ist, was wäre es aus deiner Sicht, was man sich hier auf jeden Fall mitnehmen sollte?
Paula: Wenn alles zu viel ist, wenn zu viel Arbeit ist, wenn wenn wir nicht wissen, wo wir anfangen sollen. Fang einfach immer wieder am Anfang an ganz oben bei der Mission und dein 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.
Dennis: Gut. Das war schön.
Dave: Das waren schöne Abschlussworte. Ja. Fand die Frage gut?
Dennis: Nee, aber
Dave: aber abgeschlossen, aber Ja,
Dennis: aber ja, aber Paulo hat es trotzdem sehr schön, also in dem Fall hat sie sehr schön abgebunden und das war 'n schönes Ende der Folge. Aber es war auch einfach inhaltlich nicht ganz richtig zu sagen, das ist die Standardfrage, die wir stellen. Das haben wir nämlich noch nie gemacht.
Dave: Nein, nein, nein, weil Aber deine Standardfrage.
Dennis: Ach so, meine Standardfrage. Ach, die
Dave: wenn ich moderiere.
Dennis: Die hast Du heute neu eingeführt. Das ist
Dave: die Standardfrage, wenn ich moderiere.
Dennis: Ah, okay.
Dave: Das ist genau.
Dennis: Das ist eine tolle Frage, der.
Dave: Ja, oder?
Dennis: Ja. Ja. Weil auch nach den 50 Minuten, wenn keiner zugehört hat, der hört auch die letzten 2 Minuten. Na ja, das ist son Aber dann schneiden wir das einfach direkt an Anfang. Stimmt.
Paula: Son Preview. Son TLD AM
Dave: Anfang. Genau, TLD AM Anfang. Da lohnt sich's am meisten.
Dennis: Sehr gut. Neues Format. Neues Format.
Paula: Mhm. Hat mir
Dave: schon mal probiert, war nicht gut. Gut. Dann an der Stelle Paula, vielen Dank. Es war eine sehr, sehr angenehme Folge.
Paula: Ja, vielen Dank, dass ich hier sein durfte.
Dave: Ich fand's sehr, sehr gut. Dennis, auch dir danke noch mal als Co Host. Du hast einen fantastischen Job gemacht heute.
Dennis: Dieses Lob kann ich natürlich nur zurückgeben, Dave, an deine 1. Anmoderierte Folge, die Du hattest. Und auch besonders an dich voller.
Dave: Genau. Du
Dennis: hattest ja, glaub ich, 'n bisschen, ist die, ich weiß nicht, ob Zweifel zu groß ist, aber ein bisschen Unsicherheiten, ob ein Podcast was ist.
Paula: Ja, mein erster Podcast ist
Dennis: positiv, wo ich weiß und ich, mein Bauchgefühl sagt, ja. Das war eine sehr gute Folge.
Paula: Okay, ach das Freunde.
Dennis: Es hat wirklich Spaß gemacht, mit dir zu reden. Es war sehr, sehr angenehm.
Dave: Geh in der Podcast. Ja, okay. Ich weiß, Du bist Also ich würde
Dennis: auch das, es wäre schön, wenn man sich zwischen direkt, fänd ich gut, wenn das 'n großes Ding
Dave: wird, die
Dennis: Vermieter. Weißt Du, genau. Genau. Dann wir dann recherchieren die Leute.
Paula: Hab ich das nicht durchdacht, dass das wirklich Ja,
Dave: aber jetzt
Paula: jetzt muss es so sein. Ja, ja, ist vorbei.
Dave: 10000 von Leuten wischen.
Paula: Es war irgendwann so, wie nehm ich das? Ach, wenn das so?
Dennis: Und dann, ja, in so Recherche, fragst die KI und wo kommt das irgendwie her? Und dann, ja, wurde erstmals erwähnt, den Programmierpodcast. Ah, das ist gut.
Paula: Ja. So,
Dave: das das ist wirklich sehr gut.
Paula: Ja. Ja.
Dave: Schön. Dann, bevor wir die Folge komplett beenden, Wie Du das
Dennis: kannst, Dave?
Dave: Lasst gerne Feedback da unter Podcast at Programmier Punkt bar. Wir reagieren auf alles. Schreibt uns auch in den Kommentaren bei Spotify, Apple Podcast und wo sonst auch immer. Ich glaub, ja, nichts bleibt ungelesen von TikTok,
Dennis: das neue Ding. TikTok? Mhm.
Dave: Oh, stimmt. Hast Du sogar einen Hate Kommentaren nicht gemacht. Ich erinnere mich. Ja. Ansonsten vielen Dank fürs Zuhören. Habt einen wundervollen Tag und wir sehen uns ganz bald wieder. Tschüssi. Bis denn. Mach's
Dennis: gut. Danke Fräulein.

Vision to Act Pyramide mit Paula Ostmann

Shownotes

Speaker Info

Dr. Paula Ostmann