Easy Agile Podcast Ep.13 Agile Arbeitsweisen überdenken, wobei Vielfalt, Gerechtigkeit und Inklusion im Mittelpunkt stehen
„Die Folge zeigt, dass Interaktion, Zusammenarbeit und die Unterstützung jedes Teammitglieds darin bestehen, sein Potenzial auszuschöpfen“ - Terlya Hunt
In dieser Folge chatten Terlya Hunt, Head of People & Culture bei Easy Agile, und Caitlin Mackie, Marketing Coordinator bei Easy Agile, mit Jazmin Chamizo und Rakesh Singh.
Jazmin und Rakesh sind Hauptautoren des kürzlich veröffentlichten Berichts „Reimagining Agility with Diversity, Equity and Inclusion“.
Der Bericht untersucht die Schnittstelle zwischen Agilität, Geschäftsagilität und Diversität, Gerechtigkeit und Inklusion (DE&I) sowie den Stand von Inklusivität und Gerechtigkeit in agilen Organisationen.
„Die Menschen sind das schlagende Herz von Agile. Wenn Menschen nicht durch ein inklusives und gerechtes Umfeld gestärkt werden, funktioniert Agilität nicht. Wenn Agile nicht funktioniert, können agile Organisationen nicht funktionieren.“
📌 Was hat dazu geführt, dass der Bericht geschrieben wurde
📌 Wo die Fehlstellungen liegen
📌 Was wir als Einzelpersonen und Führungskräfte anders machen können
Abonniere unbedingt, genieße die Folge 🎧
Transkript
Terlya Hunt:
Hallo zusammen. Vielen Dank, dass Sie sich uns für eine weitere Folge des Easy Agile-Podcasts angeschlossen haben. Ich bin Terlya, People & Culture-Geschäftspartnerin bei Easy Agile.
Caitlin Mackie:
Und ich bin Caitlin, Marketingkoordinatorin bei Easy Agile. Und wir werden Ihre Moderatoren für diese Folge sein.
Terlya Hunt:
Bevor wir beginnen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, unsere Anerkennung aussprechen, dem Volk der Wodiwodi der Dharawal-Nation, und den Ältesten in Vergangenheit, Gegenwart und Entwicklung unseren Respekt erweisen und allen Aborigines, die uns heute zuhören, den gleichen Respekt erweisen.
Caitlin Mackie:
Heute werden wir von Jazmin Chamizo und Rakesh Singh begleitet. Sowohl Jazmin als auch Rakesh sind Hauptmitwirkende und Forscher von Reimagining Agile for Diversity, Equity and Inclusion, einem Bericht, der die Schnittstelle zwischen agiler Geschäftsagilität und Vielfalt, Chancengleichheit und Inklusion untersucht und im Mai 2021 veröffentlicht wurde.
Terlya Hunt:
Wir freuen uns sehr, dass Jazmin und Rakesh heute zu uns kommen. Also lass uns reinspringen.
Caitlin Mackie:
Also Jazmin und Rakesh, vielen Dank, dass ihr heute zu uns gekommen seid. Wir freuen uns sehr, heute hier bei Ihnen beiden zu sein und das Gespräch zu führen. Ich nehme an, heute packen wir aus und stellen Ihnen Fragen zu dem Bericht, an dem Sie beide maßgeblich mitgearbeitet haben, Reimagining Agility with Diversity, Equity and Inclusion. Also für unser heutiges Publikum, das den Bericht vielleicht noch nicht kennt, Jazmin, könntest du uns bitte zusammenfassen, worum es in dem Bericht geht?
Jasmin Chamizo:
Absolut. Und zunächst einmal vielen Dank, dass Sie uns heute hier haben und dass Sie sich für unseren Bericht interessieren. Nur um Ihnen einen kleinen Einblick in unsere Forschung zu geben und wie alles begann. Der Gründer und Inhaber des Business Agility Institute, Evan Leybourn, nahm tatsächlich an einem Vortrag von Mark Green teil. Und Mark, der früher, ich meine, ein Agile-Coach war, bezog sich auf seine nicht sehr positive Erfahrung mit Agile. Das erregte also tatsächlich die Aufmerksamkeit von Evan, der wie wir alle ein großer Verfechter von Agilität war. Und sie beschlossen, sich auf dieses Abenteuer einzulassen und einige Nachforschungen anzustellen, um die potenzielle Beziehung zwischen Diversität, Gleichheit und Inklusion und Agilität zu untersuchen.
Also hatten wir, ich meine, zu Beginn der Forschung ein paar Hypothesen. Und die erste Hypothese war, dass agile Unternehmen trotz der positiven Absicht von Agilität und trotz der positiven Denkweise und der Werte von Agile, die wir alle teilen, Gefahr laufen könnten, marginalisierte Mitarbeiter und Kunden weiter auszuschließen. Und die zweite Hypothese, die wir hatten, war, dass Organisationen, die Vielfalt, Gleichheit und Inklusion tatsächlich direkt in ihre Agile-Transformation und dann in ihre Strategie einbetten, diejenigen Organisationen übertreffen könnten, die dies nicht tun. Wir haben also tatsächlich mehr als ein Jahr damit verbracht, verschiedene Teilnehmer aus vielen verschiedenen Ländern zu interviewen. Und am Ende haben wir festgestellt, dass diese Hypothesen wahr sind. Und heute möchten wir mit Ihnen, ich meine, einen Teil dieser Forschung teilen und müssen Sie auch ermutigen, den gesamten Bericht zu lesen und auch zu dieser Diskussion beizutragen.
Terlya Hunt:
Unglaublich. Und Jazmin, du hast das in deiner Antwort gerade ein bisschen angesprochen, aber ich denke, Rakesh, könntest du uns etwas mehr darüber erzählen, was die Inspiration und der Auslöser für das Schreiben dieses Berichts war?
Rakesh Singh:
Ja. Also danke für die nochmalige Einladung. Und es ist ein großartiger [unhörbarer 00:03:51] Vortrag über dieses wunderschöne Projekt. Das BAI beschäftigte sich schon lange mit dieser Aktivität, und ich habe zufällig eine der Präsentationen von Evan gehört, und diese Präsentation hat mein Interesse an Business Agility und den Zusammenhang mit DEI geweckt. Das war also eine Sache. Und zweitens, als Evan über dieses spezielle Projekt sprach und uns alle einlud, war ich seit etwa drei Jahrzehnten sehr lange mit der Transformation in meinem Job bei Siemens beschäftigt. Und wir stellten fest, dass es immer einige Leute gab, die, wann immer man Veränderungen vornimmt, nicht interessiert oder skeptisch waren. „Wir verschwenden unsere Zeit.“ Und okay, das war zu erwarten, aber was war überraschend, dass Agile im großen Stil an Bedeutung gewann und die Leute dachten: „Okay. Das ist eine Lösung für all unser Elend. „Obwohl der Schwerpunkt auf Kultur lag, war Kultur immer noch unser größtes Problem. Mir kam es also so vor, als würden wir das Problem nicht wirklich angehen.
Und während Jazmin über unser Ziel und unsere Hypothese sprach, war das für mich attraktiv, dass mir dieses Projekt vielleicht helfen wird zu verstehen, warum einige [unhörbar 00:05:12] die Leute in einen Teil der Agile-Transformation mit einbeziehen.
Terlya Hunt:
Ich danke dir. Das war großartig. Ich denke, in dem Bericht kommt definitiv zum Ausdruck, dass dies ein Thema ist, das Ihnen allen am Herzen liegt. Und in dem Bericht, den Sie erwähnt haben, gibt es einen Mangel an Konsens und einige Unstimmigkeiten bei der Definition einiger dieser Schlüsselbegriffe. Ich dachte, um das heutige Gespräch zu gestalten, Jazmin, könntest du uns einige dieser Schlüsseldefinitionen vorstellen: Agilität, Diversität, Gerechtigkeit und Inklusion?
Jasmin Chamizo:
Das ist jetzt eine großartige Frage, denn im letzten Jahr gab es einen großen Boom bei verschiedenen Themen im Zusammenhang mit Vielfalt, Gerechtigkeit und Inklusion, ich meine, insbesondere mit der Black Lives Matter-Bewegung und vielen verschiedenen Ereignissen, die unsere Gesellschaft im Allgemeinen beeinflusst haben. Und mit dem Aufkommen sozialer Bewegungen, ich meine, wurde viel über Diversität, Gerechtigkeit und Inklusion gesprochen. Und wenn wir über Agilität, Gleichheit, Gerechtigkeit, Inklusion und Diversität sprechen, dann meine ich, es ist sehr wichtig, ein sehr klares Verständnis davon zu haben, was wir mit diesen Begriffen meinen. Agilität ist die Denkweise. Ich meine, es geht wirklich darum, den Kunden, die Menschen, in den Mittelpunkt der Organisation zu stellen. Wir sprechen also von agilen Arbeitsweisen. Wir sprechen von kollaborativeren Arbeitsweisen. So können wir das Beste aus den Menschen herausholen und dann Innovationen entwickeln und Produkte so schnell wie möglich auf den Markt bringen.
Als wir nun über Agilität und diese ganze Idee nachgedacht haben, Menschen in den Mittelpunkt und Kunden in den Mittelpunkt der Organisation zu stellen, damit wir sehr agil und flexibel auf die Herausforderungen reagieren können, die unsere Gesellschaft derzeit darstellt, fanden wir viele Gemeinsamkeiten und viele Ähnlichkeiten in Bezug auf Vielfalt, Gerechtigkeit und Inklusion. Wenn wir jedoch über Diversität, Gerechtigkeit und Inklusion sprechen, gibt es einige Nuancen in den Konzepten, die wir verstehen müssen. Vielfalt bezieht sich wirklich auf die Mischung. Es bezieht sich auf Zahlen, auf Statistiken, auf all die Unterschiede, die wir haben. Es gibt eine sehr lange Liste von Arten von Vielfalt. Geschlechtervielfalt, sexuelle Orientierung, Denkweisen, unser sozioökonomischer Status, Bildung und was auch immer, verschiedene Arten von Vielfalt.
Wenn wir jetzt über Gleichheit sprechen, meine ich, wir sprechen davon, dieselben Ressourcen und Unterstützungsstrukturen einzusetzen, ich meine, für alle. Gleichheit beinhaltet jedoch nicht wirklich das Element der Gerechtigkeit, was so wichtig ist, wenn wir jetzt über die Schaffung inklusiver Umgebungen sprechen. Bei Chancengleichheit sprechen wir über das Element der fairen Behandlung, wir sprechen über soziale Gerechtigkeit, wir sprechen davon, allen den gleichen Zugang zu Chancen zu gewähren. Es geht also so ziemlich darum, die Situation auszugleichen, sodass all diese Stimmen Teil des Gesprächs sein können und jeder zur Entscheidungsfindung in Organisationen und in der Gesellschaft beitragen kann. Es ist also dieses Element der fairen Behandlung, es ist das Element der sozialen Gerechtigkeit, zu dem das Element der Gerechtigkeit beitragen muss und dem wir wirklich Aufmerksamkeit schenken müssen.
Und bei Inklusion geht es wirklich darum, Menschen in der Organisation willkommen zu heißen. Es geht darum, alle Bedingungen zu schaffen, damit Menschen, jeder, gedeihen und jeder in einer Organisation erfolgreich sein kann. Ich denke, es ist sehr wichtig, diese Definitionen sehr klar zu haben, um besser zu verstehen, wie sie sich überschneiden und wie es tatsächlich, ich meine, eine symbiotische Beziehung zwischen diesen Konzepten gibt.
Caitlin Mackie:
Ja. Großartig. Und ich denke, dass Agile funktioniert, wenn man nur darauf aufbaut, Interaktion, Zusammenarbeit und die Unterstützung jedes Teammitglieds dabei unterstützt, sein Potenzial auszuschöpfen. In Ihrem Bericht wird also erörtert, dass sich diese Werte in Bezug auf Vielfalt, Gerechtigkeit und Inklusion stark überschneiden. Also ich denke, Rakesh, was sind die wichtigsten Überschneidungen? Es scheint, dass diese Eigenschaften und Merkmale Hand in Hand gehen. Wie nehmen wir sie also an?
Rakesh Singh:
Wenn Sie also sehen, dass die meisten Unternehmen große Organisationen sind und seit etwa zwei Jahrzehnten bestehen, und Sie sie mit der Startup-Organisation vergleichen, dann arbeiten die Leute in der traditionellen Struktur normalerweise sozusagen in ihren funktionalen Silos. Und so wird die agile Transformation von einer Geschäftsfunktion übernommen. Es könnte ein Qualitätsteam sein. Es könnte ein Übertragungsteam sein. Und DEI ist normalerweise eine Domäne einer Personalabteilung oder von Personen, die der Organisation beitreten. Und das Problem ist, dass diese Initiativen manchmal getrennt behandelt werden und die erforderliche Zusammenarbeit nicht stattfindet, wohingegen sie in einem Startup-Unternehmen diese Art von Abteilungen nicht haben.
Wenn wir das als Grundlage betrachten, müssen wir darauf achten, dass die Organisation dafür sensibilisiert wird, dass sie an einigen dieser Projekte zusammenarbeiten, und uns die zugrunde liegenden Gemeinsamkeiten ansehen, und wir können uns möglicherweise entweder gegenseitig helfen oder uns ergänzen, denn ein Beispiel ist, wenn ich das nennen kann, es sehr einfach ist, eine agile Transformation in Bezug auf ein Geschäftsergebnis zu rechtfertigen, okay, aber jede Veränderung in Bezug auf Mitarbeiter ist eine sehr langfristige Veränderung. Sie können das also nicht mit einem Geschäftsergebnis in einem kürzeren Zeitrahmen in Verbindung bringen. Deshalb nenne ich Agile und DEI als symbiotisch. Agile kann durch einen DEI-Prozess unterstützt werden, und DEI selbst kann durch ein Agile-Projekt gerechtfertigt werden. Sie sind also symbiotisch.
Nun, was ist das Gemeinsame zwischen den beiden? Es gibt also vier Artikel. Ich meine, es gibt viele Dinge, die gemeinsam sind, aber vier Dinge, die ich für am wichtigsten halte. Ja? Das Erste ist Respekt vor den Menschen, wie es Jazmin gesagt hat, inklusiv zu sein. Respekt vor den Menschen, sowohl Agile als auch DEI, das ist eine Grundlage dafür. Und dafür sorgen, dass sich die Menschen willkommen fühlen. Also egal, aus welcher Vielfalt sie kommen, welchen Hintergrund sie haben, sie fühlen sich willkommen. Ja? Der zweite Teil ist das Arbeitsumfeld. Es ist also eine große Herausforderung, eine Art psychologische Sicherheit zu schaffen. Und ich denke, die Leute organisieren sich jetzt, das Management versteht jetzt, dass sie denken, dass sie für einen sicheren Ort gesorgt haben, aber die Menschen fühlen sich dort aus irgendeinem Grund immer noch nicht sicher. Das ist eine Sache.
Die andere Sache ist, dass unabhängig von den Richtlinien, die Sie schreiben, Dokumentationen, Richtlinien oder Ankündigungen, die grundlegenden Dinge, die die Leute sehen, sie fair und transparent sind? Ja? Also ich habe immer gesehen, dass, wenn zwei Personen einen Bonus bekommen, wenn eine Person 5% mehr bekommt, egal wie hoch der Betrag ist, immer das Gefühl hat: „Ich habe meine Schuld nicht bekommen.“ Ja? Also sei fair und sei transparent. Und das letzte ist, dass Sie in Menschen investieren müssen. Die Organisation muss in Menschen investieren. Die Organisation muss investieren, um ihnen die Möglichkeit zu geben, neue Chancen zu nutzen und auch zu wachsen und durch Lernen zu wachsen. Das sind also vier Dinge, die ich mir vorstellen kann und die tatsächlich dazu beitragen können, sowohl ein agiles als auch ein integratives Umfeld im Unternehmen zu haben.
Caitlin Mackie:
In dem Bericht wird erwähnt, dass einige dieser Möglichkeiten zur Kombination von Agilität und Inklusion im Bereich Vielfalt übersehen werden. Warum glaubst du ist das so?
Rakesh Singh:
Ich denke, der Grund, warum sie übersehen werden, ist, dass es im Grunde darum geht, die Führungskräfte auszubilden. Es ist nur so, wenn ich in der agilen Welt bin, ist mir nicht wirklich bewusst, dass es bestimmte Aspekte gibt, die mit Menschen zu tun haben. Ich denke, wenn ich nur eine Ankündigung mache, werden die Leute mitmachen. In Ordnung? Also das ist das Verständnis. Auf der anderen Seite erhielten wir Beiträge von einigen Antwortenden, die sagten, dass einige der DEI-Projekte im Grunde nur Worte sind und nicht wirklich ernsthaft damit umgehen. Das ist Zeitverschwendung. „Ich werde gezwungen, ein bestimmtes Training zu absolvieren. Ich bin gezwungen.“ Also was die Aufrichtigkeit angeht, manchmal fehlt es an etwas, also müssen die Mitarbeiter auf Führungs- und Mitarbeiterebene besser geschult werden.
Caitlin Mackie:
Ich denke, ein wirklich interessanter Hinweis in Ihrer Forschung ist, dass viele agile Prozesse und Rituale so konzipiert sind, dass sie für die Mehrheit geeignet sind, was Teammitglieder mit unterschiedlichen Eigenschaften ausschließt. Jazmin, was sind einige dieser Rituale?
Jasmin Chamizo:
Ja, das ist eine gute Frage. Wenn Sie nun an agile und agile Rituale denken und zum Beispiel, ich meine, tägliche Standups, dann haben viele dieser Rituale nicht wirklich über Diversität oder das Design von Vielfalt und Inklusion nachgedacht. Ich meine, Agile ist sehr spontan und eine Art von Ritualen, wer kann schon sprechen. Aber es gibt eine Menge Leute, ich meine, die vielleicht mehr Zeit brauchen, um Informationen zu verarbeiten, bevor sie Eingaben machen können, und zwar so schnell. Diese Anforderung, Informationen zu verarbeiten oder Eingaben sehr schnell in täglichen Standups zu geben, übersieht vielleicht die Tatsache, dass viele Menschen mit einer anderen Art von Gedankenverarbeitungsstilen oder Präferenzen möglicherweise mehr Zeit benötigen, um diese Prozesse durchzuführen.
Das wäre also, ich meine, Nummer eins; die Tatsache, dass es sehr genau vor Ort ist und manchmal nur die lauten Stimmen zu hören sind. Wir verpassen also möglicherweise viele Gelegenheiten, wenn wir versuchen, Feedback und Input von Menschen mit unterschiedlichen Denkstilen zu erhalten.
Wenn Sie nun an Organisationen in verschiedenen Ländern denken, in denen Englisch nicht die Muttersprache vieler Menschen ist, fühlen sie sich möglicherweise ebenfalls stark benachteiligt. Das passiert oft in multinationalen Organisationen, wo Leute, deren Muttersprache, Sie wissen schon, Englisch ist, sich selbstbewusster fühlen und es sind, die jetzt die Konversationen praktisch monopolisieren können. Also, für Leute, deren Muttersprache nicht Englisch ist, ich meine, sie könnten sich benachteiligt fühlen.
Wenn Sie an ältere Mitarbeiter denken, die manchmal nicht Teil einer agilen Transformation sind, haben sie möglicherweise auch das Gefühl, nicht Teil des Teams zu sein, und sie haben möglicherweise nicht das Gefühl, dazuzugehören, was bei einer agilen Transformation und für jedes Unternehmen so wichtig ist. Ein anderes Beispiel, ich meine, wären Menschen, die aufgrund ihres religiösen Glaubens, ich meine, vielleicht fünfmal am Tag beten müssen, und ich meine, vielleicht bedeutet ein morgendliches Aufstehen sehr schwer, sich daran anzupassen, oder sogar Menschen mit Behinderungen oder Sprachunterschieden fühlen sich ein wenig eingeschüchtert von Agilität. Es gibt also viele verschiedene Beispiele. Und der Doug-Bericht sammelt tatsächlich mehrere gelebte Erfahrungen der Befragten, die wir interviewen. Sie veranschaulichen, wie Agilität für die Mehrheit und für eine dominantere Kultur konzipiert wurde. Dies unterstreicht die Notwendigkeit, viele dieser Rituale und viele dieser Praktiken neu zu gestalten.
Caitlin Mackie:
Ja, ich denke, darauf aufbauend haben Sie in Ihren Empfehlungen erwähnt, dass Sie diese agilen Arbeitsweisen bewusst neu gestalten und neu gestalten wollen. Auf welche Weise können wir diese überdenken und bewusst gestalten?
Jasmin Chamizo:
Mm-hmm (bejahend). Nun, die gute Nachricht ist, dass es während unserer Recherchen und während unserer Feldarbeit und der Gespräche, die wir mit einigen Organisationen geführt haben, gezeigt hat, dass es viele Unternehmen und Organisationen gibt, die sie aktiv umsetzen, verschiedene Arten von Praktiken, angefangen bei der Art und Weise, wie sie ihre Besprechungen, ihre Rituale, ihre Stand-ups organisieren und den Menschen die Möglichkeit geben, auf unterschiedliche Weise zu kommunizieren. Vielleicht etwas Raum für Stille geben, damit die Leute ihre Informationen verarbeiten können, oder alternative Kanäle bieten, über die Menschen entweder schriftlich oder vielleicht am nächsten Tag kommunizieren und Kommentare abgeben können. Es muss also nicht direkt vor Ort sein, und sie fühlen sich nicht unter dieser Art von Druck.
Nun, ein anderes Beispiel wäre, Menschen zu erlauben, auch in ihrer Muttersprache zu kommunizieren. Ich meine, nicht unbedingt Englisch zu benutzen, ich meine, die ganze Zeit als, ich meine, Hauptsprache. Ich denke, es ist auch wichtig, dass die Mitarbeiter das Gefühl haben, dass sie mit ihrer eigenen Sprache dazu beitragen können, und dass sie auch anfangen, die Erfahrung der Mitarbeiter zu analysieren, ich meine. Wir sprechen davon, vielleicht nichtbinäre Optionen in Rekrutierungsprozessen oder bei der Gehaltsabrechnung zu verwenden. Also, ich meine, damit anzufangen, die verschiedenen Praktiken inklusiver zu gestalten und, ich meine, die gesamte Mitarbeitererfahrung zu analysieren. Ich meine, das sind einige Beispiele, mit deren Umsetzung wir beginnen können, um ein integrativeres Umfeld zu schaffen. Und das, was für mich am wichtigsten ist, ist die Ermutigung von Führungskräften, bewusst integrative Arbeitsumgebungen zu gestalten, beispielsweise durch die Schaffung von Umgebungen, in denen sich die Menschen wirklich sicher fühlen, in denen sie dies haben. Psychologisch sicher.
Terlya Hunt:
Der ganze Abschnitt über das Erforschen und Hinterfragen bestehender Überzeugungen ist so interessant. Und ich würde auf jeden Fall jeden, der zuhört, ermutigen, ihn zu lesen. Ich könnte Ihnen allein zu diesem Abschnitt so viele Fragen stellen, weil ich denke, er war voller Gold, und ehrlich gesagt, mein Exemplar ist hervorgehoben und gekritzelt und ich habe es gelesen und immer wieder gelesen, es gab so viel zu absorbieren. Das Erste, was mir als HR-Praktiker in einer agilen Organisation wirklich auffiel, war die Überzeugung, dass es ein guter Anfang ist, sich zuerst auf ein oder zwei Bereiche der Vielfalt zu konzentrieren. Und aufgrund Ihrer Recherchen haben Sie tatsächlich herausgefunden, dass die Umfrageteilnehmer diese Methode als unwirksam und sogar schädlich für DEI empfanden. Und in Ihrer Recherche verweisen Sie auch darauf, wie wichtig es ist, bewusst und überlegt vorzugehen. Ich schätze, wie bringen wir dieses Bedürfnis nach Konzentration und Veränderung mit diesen Erkenntnissen in Einklang, dass eine zu enge Fokussierung tatsächlich schädlich sein kann? Ich könnte dir das hier vorwerfen, Rakesh.
Rakesh Singh:
Dank des Reformdatenberichts, der sehr interessant ist, haben wir ihn sogar einer ganzen Reihe von Gruppen vorgestellt. Und eines der Dinge, die ich beobachtet habe, als wir über einige der Überzeugungen und Herausforderungen sprachen, war, dass sofort die Antwort kam: „Hey, wir haben Erfahrung in unserer Region.“ Wir haben also erkannt, dass dieser ganze Aspekt, über den Jazmin sprach, viele Dimensionen hat. Wenn Sie sich also Inklusivität, Diversität und Gleichheit in der gesamten Organisation ansehen, gibt es viele Ströme und viele Auslöser. Unter Diversität verstehen wir, okay, in sehr begrenzter Weise, es kann das Geschlecht sein, oder es kann eine Religion oder ein Land sein, aber in Wirklichkeit ist es viel mehr in einem Arbeitsumfeld, es gibt viele Dynamiken, die [unhörbar 00:22:15] sind. Die Herausforderungen, die wir gesehen haben, waren, dass, wenn man ein Projekt auf eine sehr aufrichtige Art aufgreift und sagt: „Ich löse ein Problem, okay?“ Lass mich sagen, ich löse ein Problem einer Region oder Sprache, ja? Das Problem ist nun, dass wir uns meistens das dominanteste ansehen und dieses Problem identifizieren.
Was also passiert, ist, dass Sie genau dort eine Ungleichheit schaffen, weil es andere Menschen gibt, unter denen sie leiden. Sie leiden, ich werde nicht sagen, „leiden“, aber sie werden von anderen Faktoren der Vielfalt beeinflusst und sie hatten das Gefühl: „Okay, niemand kümmert sich wirklich um mich.“ Ja? Man muss es also in einem sehr ganzheitlichen Bild betrachten, und man muss es so betrachten, dass alle mit an Bord sind, ja? Sie können also vielleicht nicht für jedes spezifische Problem eine Lösung finden, aber alle mit ins Boot holen und die Leute in einem Teil der Umgebung oder entweder in der psychologischen Sicherheit oder auf der politischen Ebene arbeiten lassen, also schaffen Sie ein Umfeld, in dem jeder teilnehmen kann, und die Probleme können unterschiedlich sein, sodass sie ihre eigenen Probleme ansprechen und sicherstellen können, dass sie das Gefühl haben, dass sie betreut werden. Und genau das haben wir tatsächlich beobachtet.
Terlya Hunt:
Und die zweite Überzeugung, die ich für wirklich interessant hielt, war die, dass wir uns an die Überzeugungen von jemandem anpassen, wenn er danach fragt. Und Ihre Untersuchungen haben ergeben, dass nicht jeder in der Lage ist, seine Bedürfnisse offenzulegen, egal wie sicher die Arbeitsumgebung ist. Deshalb ist es der erste Schritt in diesem Prozess, sich auf die Offenlegung zu verlassen. Organisationen werden immer einen Schritt hinterherhinken und die Last des Wandels auch marginalisierten Gruppen aufbürden. Was können wir tun, Rakesh, um diesen Druck abzubauen und proaktiver zu werden?
Rakesh Singh:
Es gibt also ein paar Dinge, auf die wir achten müssen, wenn wir mit Leuten sprechen. Tatsächlich haben sie über das Problem gesprochen und sie haben auch empfohlen, was richtig sein könnte, wir tun es. Und wir haben auch untereinander darüber gesprochen. Eines war also ganz klar: Es gab ein paar Zweifel an der Aufrichtigkeit der Führung. Deshalb waren wir der Meinung, dass jede Organisation, in der die Führungskraft sehr proaktiv war, wie zum Beispiel, was ist der Hauptgrund, wenn ich ein Problem habe, wenn ich darüber spreche, ich mir immer Sorgen mache, was passieren wird, wenn ich es enthülle? Und ist es das richtige Thema, um darüber zu sprechen? Das sind also die Fragen, die viele Menschen davon abhalten würden, überhaupt nicht darüber zu sprechen. Hier kann die proaktive Führung den Menschen helfen, ihre Hemmungen zu überwinden und darüber zu sprechen, und wenn sie nicht darüber diskutieren, werden Sie nie wissen, ob es ein Problem gibt. Also, das ist die eine Sache. Also, das ist der Ansatz.
Es gibt also ein paar Dinge, die wir auch empfehlen könnten, ist proaktive Führung von Anfang an, und etwas, das getan werden kann, ist, dass den Managern viele Tools zur Verfügung stehen, ja? Leute, Führungskräfte, würde ich das nennen. Dinge wie Coaching, Sie haben also ein Wachstumsmodell, in dem Sie eine einzelne Person coachen können, sogar als Manager oder als unabhängiger Coach, und dann mit Moderationstechniken. Als ich meine Karriere begann, war das kein Training zum Thema Moderation, ich ging einfach in den Raum und leitete das Meeting. Aber es sind sehr nette Werkzeuge, Moderationstechniken, die eingesetzt werden können, um die Leute zur Teilnahme zu bewegen. Solche Dinge können also sehr nützlich sein, um proaktiv zu sein und Menschen aus ihrer Hemmung zu holen. Das ist auf jeden Fall Sache des Leiters. Deshalb nennen wir es dienende Führung. Es ist ihre Aufgabe, die Initiative zu ergreifen und die Führung zu übernehmen und die Menschen aus ihrer Schale zu holen.
Terlya Hunt:
Es passt ziemlich gut zu der nächsten Frage, die mir in den Sinn kam. Ihr beide habt heute tatsächlich eine Menge herausfordernder Überzeugungen erwähnt und Dinge herausgefordert. Wir müssen dieses Bewusstsein stärken, sichere Räume schaffen und psychologische Sicherheit in unseren Teams schaffen. Was sind einige Beispiele dafür, wie wir sichere Räume für diese Gespräche schaffen können?
Rakesh Singh:
Die Beispiele für jemanden, der sichere Orte schafft, sind... Ich würde sagen, das ist die Ausbildung von Menschen und Führungskräften. Was ich gesehen habe, ist, dass, wenn das Führungsteam das erkennt und die Manager und andere Leute weiterbildet... Man muss tatsächlich Mitarbeiter auf verschiedenen Ebenen schulen und ein Umfeld schaffen, in dem alle an der Entscheidungsfindung beteiligt sind und es ihnen freisteht, Entscheidungen zu treffen, natürlich innerhalb der Grenzen des Unternehmens.
Der Schwerpunkt, so würde ich sagen, ist, dass es viele Bildungsprogramme gibt und die Leute sich gerne weiterbilden würden, weil ich normalerweise das Gefühl hatte, nie zu einer guten Führungskraft ausgebildet worden zu sein. Es gab nie eine Ausbildung. Aber heutzutage stellen wir fest, dass viele Bildungsprogramme auf verschiedene Themen eingehen, wie Mikroaggressivität, unbewusste Vorurteile, psychologische Sicherheit. Die Leute sollten es verstehen. Dinge wie einfühlsam zu sein. Diese Terminologien gibt es, aber ich finde, dass die Leute sie nicht wirklich schätzen und nicht in dem Maße verstehen, wie sie es brauchen, obwohl sie in einer Führungsposition sind.
Caitlin Mackie:
Danke fürs Teilen, Rakesh. Mir gefällt wirklich, was Sie zum Thema proaktive Führung erwähnt haben. Ihre Studie ergab, dass 47% der Befragten der Meinung sind, dass Unternehmen, die diese Einheit aus Agilität, Vielfalt, Gleichheit und Inklusion erreicht haben, von den Vorteilen profitieren und die Konkurrenz hinter sich lassen werden. Jazmin, was haben diese Organisationen anders gemacht?
Jasmin Chamizo:
Ja. Das ist eine gute Frage. Eigentlich passt das sehr gut zur Vorstellung von dienender Führung, inklusiver Führung und dazu, dass Führungskräfte vor dieser unglaublichen Herausforderung stehen, Arbeitsbereiche zu schaffen, die psychologisch sicher sind, wie Rakesh gerade erwähnt hat. Das liegt wirklich in der Verantwortung aller, aber es hat viel mit einer sehr starken Führung zu tun.
Wir stellten fest, dass mehrere andere Organisationen, die wir interviewt haben, über ein sehr starkes Führungsteam verfügten, dass sie sich bei ihrer agilen Transformation wirklich für Vielfalt, Gerechtigkeit und Inklusion engagierten und in der Lage waren, DEI in den Mittelpunkt der Organisation zu stellen. Das ist Nummer eins: Ein sehr starkes Führungsteam, das sich tatsächlich für Vielfalt, Gleichheit und Inklusion einsetzt und die Bemühungen von DEI nicht als isolierte Maßnahmen oder Initiativen betrachtet.
Das ist etwas, das wir heutzutage oft sehen. Als DEI-Coach und Berater sieht man leider manchmal mehrere Organisationen, die es nur sehr isoliert versuchen und sehr... Sie haben keine langfristige Strategie. Wir haben gesehen, dass es tatsächlich funktioniert, dieses engagierte Führungsteam zu haben, das in der Lage war, DEI in den Mittelpunkt ihrer Strategie zu stellen.
Außerdem ein Team, das in der Lage war, sich für Vielfalt, Gerechtigkeit, Inklusion und Agilität einzusetzen, und das in der Lage ist, Fürsprecher in der gesamten Organisation zu haben. Es ist nicht nur die Aufgabe einer Person. Dies erfordert die Bemühungen der gesamten Organisation und der einzelnen Personen, sich für DEI zu engagieren und aktiv an der agilen Transformation teilzunehmen.
Ich würde auch sagen, Führungskräfte, die Fehler akzeptieren und Fehler während des gesamten Prozesses akzeptieren. Das ist etwas, das in unseren Gesprächen mit Menschen in verschiedenen Organisationen häufig zur Sprache kam, dass in vielen Kulturen und in vielen Organisationen Fehler bestraft werden. Sie werden nicht als Chance wahrgenommen.
Einer der Tipps oder Best Practices wäre, Führungskräfte zu haben, die in der Lage sind, dem Rest ihrer Organisation zu zeigen, dass Fehler tatsächlich Lernmöglichkeiten sind, dass Sie Dinge ausprobieren und innovativer sein können. Selbst wenn Sie scheitern, werden Sie nicht bestraft, oder es wird keine Konsequenzen geben, und, ganz im Land, dass dies tatsächlich eine Lernmöglichkeit ist, von der wir alle profitieren können.
Caitlin Mackie:
Ja. Ja, ich stimme vollkommen zu. Welche Vorteile haben sie gesehen?
Jasmin Chamizo:
Sie sahen definitiv ein besseres Arbeitsumfeld. In unseren Interviews mit den Befragten wurde häufig darauf hingewiesen, dass die Teilnehmer die Möglichkeit sahen, neue und innovative Ideen auszuprobieren. Definitiv mehr Innovation, mehr Kreativität. Die Geschäftsmoral ist letztlich sogar gestiegen, weil sie sahen, dass das Unternehmen tatsächlich unterschiedliche Perspektiven einnahm, auch wenn sie scheitern sollten. Dies erforderte definitiv mehr Innovation.
Ich würde sagen Innovation, mehr Kreativität und ein besseres Arbeitsumfeld. Absolut neue Produkte, neue Ideen. Wenn Sie über die aktuellen Umstände mit COVID nachdenken, müssen Organisationen genau darauf abzielen. Neue Produkte, mehr Innovation, um all den Herausforderungen zu begegnen, vor denen wir heute stehen.
Terlya Hunt:
Mächtige Dinge, über die die Zuhörer nachdenken sollten. Hier bei Easy Agile ist es unsere Mission, Teams dabei zu helfen, agil zu sein. Weil wir glauben, dass der Fokus schon zu lange auf dem Tun lag, obwohl die Realität so ist, dass Agile eine ständige Reise des Werdens ist.
Es gibt einen bestimmten Teil des Berichts, der mir wirklich aufgefallen ist und den ich gerne lesen würde. „Agilität ist eine Reise ohne festen Endpunkt. Der Weg zur Schaffung vielfältiger, gerechter und inklusiver Umgebungen ist derselbe. Agilität und DEI können angestrebt, aber nie vollständig erreicht werden. Sie sind ein Prozess des kontinuierlichen Lernens, Reflektierens und Verbesserns. Ein Team kann in den Prozess der Verbesserung der Geschäftsagilität oder der DEI nicht mit einer Einstellung zur Vollendung gehen, und jedes Modell, das Agile und DEI vereint, wird letztlich unwirksam sein, wenn die Teilnehmer nicht bereit sind, sich kontinuierlich um Selbstverbesserung zu bemühen.“
Ich liebe dieses Zitat absolut. Rakesh, lass uns das ein bisschen weiter untersuchen. Was kannst du mir dazu noch sagen?
Rakesh Singh:
Eigentlich gibt es eine interessante Sache, mit der ich zunächst teilen möchte. Wir wollten nach einer Organisation suchen, die uns hilft, ihre Leute zu interviewen und mit ihren Leuten zu sprechen. Die Art und Weise, wie Organisationen reagiert haben... Einige antworteten: „Soll ich meinen Leuten erlauben, mit jemandem zu sprechen? Es könnte ein Problem sein.“ Aber dann haben wir andere Organisationen bekommen, die uns tatsächlich verfolgt haben. „Wir würden gerne ein Teil davon sein und wir würden gerne unsere Leute interviewen lassen.“ Sie standen der ganzen Sache sehr positiv gegenüber.
Ich habe zufällig mit der DEI-Unternehmensleiterin, einer Dame, gesprochen, und sie sprach so... Ich würde sagen, sie war so begeistert von der ganzen Sache, obwohl ich zumindest das Gefühl hatte, dass sie ein sehr hohes Maß an Bekanntheit für DEI hatten. Aber das Bestreben, zu lernen und herauszufinden, was sie besser machen könnten, war ziemlich erstaunlich und ziemlich positiv.
Da lautet meine Antwort, ist das... Wenn man sich die aktuelle Pandemie anschaut und die Leute das erkannt haben, „Okay. Wir müssen von zu Hause aus arbeiten. „Anfangs fanden es einige Leute großartig. Das ist eine tolle Sache. Work-Life-Balance. „Ich kann zu mir nach Hause gehen.“ Aber nach einiger Zeit stellten sie fest, dass es ein Problem ist. Es gibt noch ein anderes Problem.
Der Punkt ist, dass sich in jeder Organisation, in der es um ein Geschäft, ein soziales Leben oder um Menschen geht, es einfach ständig ändert. Es gibt keine Methode oder Richtlinie, die für immer gültig sein wird. Es gibt einen kontinuierlichen Lernprozess, in den wir uns einlassen müssen.
Was wir tun müssen, ist uns auf unser Ziel zu konzentrieren, das wir erreichen wollen. Je nach Umfeld nennen wir das geschäftliche Agilität. Bringen Sie es jetzt auch zu den Menschen, denn es ist ein Volk... Wir sprechen über Kundenorientierung und all das. Aber herauszufinden, dass es die Menschen sind, die das liefern, was das Unternehmen will. Man muss sehen, wie sich das auf ihr Leben auswirkt.
Wir diskutieren darüber, die Leute wieder ins Büro zu bringen. Das Problem ist, dass eine Stadt wie Bangalore eine sehr teure und stark bewölkte Stadt ist. Die Leute sind in ihre Heimatstadt gegangen und können von dort aus arbeiten. Um sie zurückzuholen, müssen Sie sie nun erneut genehmigen. Um die Erklärung abzukürzen: Unser Leben verändert sich, ständig, und die Technologie und alles andere stellen uns vor... Die Menschen müssen nach Methoden und Ansätzen suchen, wie sie sich kontinuierlich anpassen können.
Lernen ist ein kontinuierlicher Prozess. Tatsächlich, als ich mit Agile angefangen habe und mich die Leute gefragt haben: „Wie viele Jahre Erfahrung haben Sie?“ Ich sage generell fünf Jahre, weil alles, was ich vor fünf Jahren gemacht habe, eigentlich die falsche Praxis ist. Man muss kontinuierlich lernen, und DEI und Agile sind in dieser Situation nicht fremd.
Caitlin Mackie:
Ich liebe das. Ich denke, die Förderung dieser kontinuierlichen Lernumgebung ist wirklich wichtig. Ich nehme an, in diesem Zusammenhang konzentrieren sich einige der Empfehlungen des Berichts auf eine vertiefte Ausbildung und gezielte Fachkenntnisse. Jazmin, welche weiteren Empfehlungen, Kurse oder Praktiker gibt es, mit denen sich die Leute nach dieser Episode beschäftigen können?
Jasmin Chamizo:
Sicher. Ein wichtiger Teil unseres Berichts war eine Reihe von Empfehlungen für die gesamte agile Community und Praktiker, für Organisationen und agile Coaches. Das kannst du sehen. Sie könnten genauere Informationen in unseren Berichten erhalten. Ich möchte Sie alle zum Lesen ermutigen. Wenn es um agile Coaches und Berater geht, ermutigen wir die Menschen auf jeden Fall, mehr über Diversität, Gerechtigkeit und Inklusion zu erfahren, denn eine der Erkenntnisse und Erkenntnisse, die wir aus dieser Studie gezogen haben, ist, dass Diversität, Gleichheit und Inklusion in der agilen Welt nicht speziell enthalten sind.
Als wir mit den Befragten in vielen verschiedenen Ländern sprachen, stellten sie nicht spontan den Zusammenhang zwischen Agilität, Agilität und Diversität, Gerechtigkeit und Inklusion her. Aber je mehr wir darüber sprachen, stellten sie fest, dass sie sich tatsächlich sehr stark überschneiden. Es gab eine symbiotische Beziehung zwischen ihnen, weil man die Person und alles, was mit dieser Person zu tun hat, in den Mittelpunkt der Organisation stellt, in die Transformation.
Auf jeden Fall ermutigen wir... Führungskräfte und agile Coaches müssen anfangen, mehr über unsere DEI zu lernen, diese Fähigkeiten auszubauen und mehr über unbewusste Vorurteile und die Auswirkungen unbewusster Vorurteile sowie Diskriminierung und Rassismus zu lernen, die wir in Organisationen weiterhin beobachten werden. Sie achten stärker auf die Stimmen, die in den aktuellen Gesprächen derzeit nicht gehört werden. Sie können verschiedene Techniken oder Methoden erlernen, um ansprechender und inklusiver zu sein.
Wenn es um die agile Community im Allgemeinen und um Influencer geht, ist es wichtig zu erwähnen, dass Evan Leybourn, der Gründer des Agility Institute, derzeit einige Gespräche mit wichtigen Institutionen der agilen Community wie der Agile Alliance führt, weil wir suchen... Das ist es, wonach die Generation Z sucht. Es gibt eine große Aufforderung an Unternehmen, sich dieser Art der Transformation zu stellen, aber DEI in den Mittelpunkt der Organisation zu stellen. Das ist es, was ich sagen möchte.
Tragen Sie zur Diskussion bei. Dies ist ein Pilotprojekt. Dass wir hoffen, mehr Forschung in anderen DEI-Bereichen im Zusammenhang mit Agilität durchführen zu können. Wir möchten, dass die Zuhörer Teil des Gesprächs sind und ihre Erfahrungen einbringen, um den aktuellen Stand der Agilität zu verbessern.
Caitlin Mackie:
Vielen Dank, dass Sie heute zu uns gekommen sind. Wir haben unser Gespräch sehr genossen. Ich kann es kaum erwarten zu sehen, wie sich Agilität und Diversität, Gerechtigkeit und Inklusion in Zukunft entwickeln werden. Ich danke dir.
Jasmin Chamizo:
Vielen Dank, dass Sie uns haben. Es war mir ein Vergnügen.
Rakesh Singh:
Vielen Dank an euch beide. Es war schön, unsere Erfahrungen zu teilen. Ich danke dir vielmals.
Verwandte Episoden
PodcastEasy Agile Podcast Ep.14 Rocking the Docs
„Ich fand es toll, den Raum zu haben, um über gemeinsame Interessen zu sprechen — alles rund um technische Dokumentation und Informationsarchitektur“ — Henri Seymour
In dieser Folge von The Easy Agile Podcast hören Sie Henri Seymour, Entwickler bei Easy Agile, mit Matt Reiner, Customer Advocate bei K15t, sprechen.
Henri & Matt sprechen über alles, was mit technischer Dokumentation zu tun hat (wir versprechen, dass diese Episode viel interessanter ist, als sie sich anhört! 😉)
✏️ Technische Dokumentation als Produkt betrachten
✏️ Der Wert einer gut geschriebenen Dokumentation
✏️ Warum du oft digital entrümpeln solltest
✏️ Informationsarchitektur
So viele Goldnuggets in dieser Folge!Abonniere unbedingt, genieße die Folge 🎧
Transkript
Henri Seymour:
Hallo zusammen. Das ist der Easy Agile Podcast. Wir haben heute eine Folge mit Matt Reiner. Ich bin dein Gastgeber für heute, Henri Seymour, Entwickler bei Easy Agile. Und kurz bevor wir mit dem Podcast beginnen, möchte ich den traditionellen Australiern des Landes, in dem ich heute aufnehme, meine Anerkennung aussprechen, dem Volk der Watiwati aus der Dharawal-Nation. Respektieren Sie die Ältesten in der Vergangenheit, Gegenwart und in der Zukunft, und erweisen Sie diesen Respekt allen Aborigines oder Bewohnern der Torres Strait Islander, die sich diese Episode anhören.
Matt ist ein erfahrener Content-Stratege mit langjähriger Erfahrung in der Computersoftwarebranche. Er kennt sich mit agilen Scrum-Frameworks, verwandten Tools, Kommunikation, technischem Schreiben, Videoproduktion, Kundeninteraktion und strategischer Planung aus. Und er ist heute hier, um mit uns über das Schreiben und insbesondere über technisches Schreiben und Dokumentation zu sprechen. Hallo, Matt.
Matt Reiner:
Hallo. Es ist toll, hier zu sein. Ja, ich bin Matt. Ich mag alle möglichen inhaltlichen Dinge. Und eines davon ist technisches Schreiben, was, wie ich finde, interessanter ist, als es klingt. Ich schätze, du musst dich bis zum Ende des Podcasts entscheiden, wenn du das glaubst.
Henri Seymour:
Experten für technische Dokumentation. Wenn Sie also speziell über technische Dokumentation sprechen, was meinen Sie damit?
Matt Reiner:
Nun, ich habe das Gefühl, dass sich dieser Begriff gerade mitten in einer großen Veränderung befindet. In der Vergangenheit hieß es in der technischen Dokumentation sehr strikt: „Okay, wir sind ein Team, wir machen etwas, ein Produkt.“ Vielleicht ist es eine App, vielleicht ist es, ich weiß nicht, ein Gokart und dafür brauchen wir eine Bedienungsanleitung. In der technischen Dokumentation hat sich jemand hingesetzt und aufgeschrieben: „Okay, hier sind alle Knöpfe und Schalter und hier ist, was sie tun. Hier sind alle Funktionen. Hier ist vielleicht der Grund, warum du sie verwenden würdest.“
Also die Zusammenstellung der Bedienungsanleitung, bei der es sich traditionell um gedrucktes Material handelte, das Sie mit dem Produkt erhalten würden. Aber im Laufe der Zeit ist es viel mehr geworden, teilweise mit dem Internet, weil wir einfach ständig an Inhalten arbeiten können, wie es viele von uns mit den Produkten tun, die unsere Teams herstellen. Und dann sehen wir es auch in neuen Formen. Vielleicht ist es kein gedrucktes Stück, tatsächlich wollen die meisten Leute keine gedruckte technische Dokumentation mehr, sie wollen sie online. Oder noch besser, sie wollen es direkt im Kontext Ihrer App haben, wenn sie sie verwenden. Sie können einfach die Informationen abrufen, die sie benötigen, und dann weitermachen.
Das ist technische Dokumentation. Sie sollte da sein, um dir zu helfen, das zu tun, was dir wirklich wichtig ist, und dann aus dem Weg zu gehen, damit du es tun kannst.
Henri Seymour:
Haben Sie eine Beschreibung, warum gute technische Dokumentation? Für Produktbenutzer ist es so wichtig, sie nicht nur zu haben, sondern sie in einer guten Qualität zu haben, sodass Ihre Benutzer wirklich davon profitieren.
Matt Reiner:
Nun, ich nehme an, wir alle finden in unserem Tag oder auf unserer Reise die Punkte, an denen wir uns befinden, an denen wir etwas erreichen wollen, aber wir wissen nicht, wie wir es machen sollen. Viele von uns haben sich also wirklich sehr daran gewöhnt, auf Google zu springen und zu sagen: „Okay, hier ist diese Sache, die ich machen möchte, wie mache ich das?“ Und es gibt eine gute technische Dokumentation mit der Antwort, die Sie benötigen, der Erklärung, die Sie benötigen. Denn letztlich sind wir alle kluge Menschen, die befähigt werden sollten, das zu tun, wofür wir eine Leidenschaft haben.
Und technische Redakteure und Kommunikatoren, die eigentlich alle Mitglieder unseres Teams sind. Leute, die sich hinsetzen, um eine gute technische Dokumentation zu erstellen, verwenden so wenig Worte wie möglich, um eine Person auf den richtigen Weg zu bringen. Und wenn es passiert, ist es einfach wie „herrlich“, nicht für den Benutzer. Sie wissen nicht einmal, dass es passiert ist, sie wussten nicht einmal, dass sie deine Texte gelesen haben. Aber für den Autor ist es wie: „Ja, ich habe es geschafft, ich habe es getan. Es ist ihnen egal, was ich getan habe, aber ich habe es getan.“ Und jetzt tun sie das, was wirklich wichtig ist.
Henri Seymour:
Das ist großartig, einen der Hauptunterschiede zu verstehen, wenn ich etwas geschrieben habe und nicht möchte, dass mein Benutzer Zeit damit verbringt. Ich möchte so wenig Zeit wie möglich damit verbringen, dies zu lesen.
Matt Reiner:
Ja, ja, ja. Sie können sehr stolz auf Ihre Arbeit sein, aber eine dieser Kennzahlen, die sich viele Leute bei Websites ansehen, ist die Zeit, die Sie auf einer Seite verbringen. Manchmal können Sie sich also etwas vormachen und denken: „Oh wow, sie haben 10 Minuten auf meiner Seite verbracht. Das heißt, meine Dokumentation ist wirklich gut.“ Aber das könnte auch bedeuten, dass es nicht sehr gut ist und sie es immer wieder lesen müssen. Die wahre Metrik ist also, sind sie zu dem gekommen, was ihnen wirklich wichtig war? Und leider ist es schwer zu messen.
Henri Seymour:
Sie haben das jetzt mit dem Aufkommen des Internets erwähnt und Ihnen die Möglichkeit gegeben, diese Dokumente auf eine Weise zu wiederholen, die Sie mit gedruckter Dokumentation nicht könnten. Diese iterative Sache bringt den agilen Prozess mit sich, etwas, das Sie bereits veröffentlicht haben, zu wiederholen und es auf die gleiche Weise zu verbessern, wie ich es als Entwickler für Produkte tue. Kannst du uns mehr über diesen iterativen agilen Prozess erzählen?
Matt Reiner:
Oh ja. Ja, es ist so wahr. Früher war die Dokumentation wieder im Wasserfall-Standard, eher in der Zeit des Produktprojektmanagements, die Dokumentation war ein wichtiger Teil davon. Sie würden dieses Projekt damit beginnen, diese riesigen Dokumente zu schreiben, in denen es heißt: „Folgendes werden wir tun. Und hier sind alle Überlegungen, und hier erfahren Sie, wie alles zusammenhängt.“ Und das hat für eine Menge Hardware wirklich gut funktioniert. Das war das Ding, das wir lange gemacht haben. Einfach alles, was die Menschheit gemacht hat, war oft Hardware, zumindest als Gruppe.
Und dann kommt plötzlich diese ganze Software-Sache und wir versuchen, sie so zu bauen, als wäre es eine physische Sache. Und wir kommen zum Ende dieses zweijährigen Softwareprojekts und die Leute sagen: „Ja, das ist nicht das, was ich wollte.“ Aber wir sagen: „Oh, aber wir gehen zurück zum Anfang und schauen uns die Dokumentation an, und das haben Sie gesagt, Sie wollten es.“ Aber jetzt, mit dem Internet und nur mit agiler Entwicklung, müssen wir wirklich weg von diesem Ort, an dem wir mit einem Stapel von Dokumenten beginnen. Und dann entwickeln wir einen weiteren Stapel von Dokumenten als unsere, ich weiß nicht, Entwicklungsrichtlinien.
Und dann unsere Testpläne, und dann endlich haben wir die Benutzerdokumentation. Stattdessen sollte die Dokumentation heutzutage eigentlich nur von einem sehr kleinen Teil des Inhalts während des gesamten agilen Entwicklungszyklus zur endgültigen Benutzerdokumentation heranwachsen. Denn es spielt keine Rolle, was wir uns vorgenommen haben, es kommt darauf an, was wir machen. Niemand, er will darüber lesen, was wir zu tun dachten, das ist reine Fiktion. Und es ist wahrscheinlich keine interessante Lektüre. Es ist wirklich das endgültige Benutzerhandbuch, das aus dem agilen Prozess hervorgeht, aber das ist eine große Änderung, aber sie ist gut.
Henri Seymour:
Ich liebe diese Vorstellung von einfach so, das wächst allmählich. Es gibt keinen bestimmten Startblock und Endblock. Es ist ein Prozess. Und Sie haben die Möglichkeit erwähnt, diese Dokumente zu wiederholen. Haben Sie irgendwelche Tipps für die Zeit, nachdem Sie Ihre technische Dokumentation digital veröffentlicht haben, indem Sie das, was Sie bereits haben, wiederholen und im Laufe der Zeit verbessern?
Matt Reiner:
Oh ja. Ich weiß, dass jedes agile Framework anders ist, aber sie alle haben diese Feedback-Phase, in der... Und das ist wirklich während des gesamten Prozesses so, aber wir müssen etwas Zeit investieren. Es gibt also viele verschiedene Dinge, die wir uns ansehen können. Ich möchte zum Beispiel nicht einfach sagen, ein Standardprogramm, das wir uns ansehen sollten, ist, Sie sollten ein Hilfecenter haben, in dem Sie etwas wie Google Analytics implementieren können, damit Sie sehen können, was sich die Leute ansehen? Wie lange schauen sie sich das an?
Eine weitere wirklich gute ist, dass Sie es separat in Google Analytics einrichten müssen. Wonach suchen die Leute auf Ihrer Website? Du kannst auch Google verwenden... das waren früher Webmaster-Tools. Ich glaube, es heißt jetzt Site Tools, aber du kannst sehen, wonach die Leute bei Google gesucht haben, bevor sie auf deine Seiten kamen. Das ist alles wirklich, wirklich wertvolles Zeug. Dann kannst du weiter fortgeschritten sein. Du kannst dir Pointer-Tracking ansehen, Apps, die du dort einbetten kannst und bei denen du ziemlich verrückte Sachen bekommst.
Aber dann solltest du auch erwägen, am Ende jeder Seite ein Forum zu haben wie: „War das hilfreich? War es nicht hilfreich? Oh, es war nicht hilfreich? Sag mir warum. Oh, es war hilfreich? Sag mir warum.“ Genau wie ein YouTube-Ersteller suchen sie nach diesem Feedback. Dieses Feedback ist wichtig, Daumen hoch. Tatsächlich ist es sehr umstritten, YouTube hat gerade angekündigt, die Zahlen mit dem Daumen nach unten zu verbergen, aber viele YouTuber sagen: „Nein, nein, nein, tu das nicht, denn das vermittelt den Wert dieses Videos, das da draußen ist.“
Es gibt also viele dieser Signale. Und dann gibt es einfach wirklich sanfte Signale, bei denen es schwer ist zu wissen, ob die Leute den Inhalt nutzen oder nicht. Weil du es vielleicht nie hören wirst. Vor allem, wenn es eines dieser Dinge ist, dass sie einfach rein und raus gehen, wirst du nichts davon hören. Aber die Feedback-Phase, es ist wirklich toll,... Jedes Mal, wenn Sie Feedback zu Ihrem Produkt erhalten, das Sie herstellen, versuchen Sie, auch Ihre Dokumentation zu veröffentlichen. Denn das ist die Zeit, in der die Leute offen dafür sind, Ihr Produkt zu erkunden und Feedback zu geben.
Warum also nicht dieselbe Dokumentation untersuchen, die dazugehörige Dokumentation, um zu sehen: „Okay, hilft das diesen Leuten tatsächlich dabei, das zu tun, was sie tun wollen? Oder sollten wir es genauso verbessern, wie wir es mit dem Produkt tun?“
Henri Seymour:
Nein, das ist wirklich gut, wenn man das vergleicht, wir haben gerade ein Produkt veröffentlicht. Geben Sie uns Feedback, wenn Sie dasselbe mit der Dokumentation tun. Denn dann wird es seinen Höhepunkt erreichen, bevor jeder den Dreh raus hat. Wir haben gerade diese Feature-Version veröffentlicht, teilen Sie uns mit, wie Sie sie verwenden, und die Dokumentation ist gewissermaßen Teil davon, insbesondere für komplexere Produkte.
Matt Reiner:
Exakt.Henri Seymour:
Haben Sie irgendeinen Hintergrund in der Kundenbetreuung? Wir führen den Kundensupport sowie deren Dokumentation intern durch. Deshalb versuchen wir, die Dokumentation zu verbessern, um die Supportbelastung unseres Teams zu verringern. Hast du irgendeinen Hintergrund in dem... Kannst du es lösen?
Matt Reiner:
Ja. Ja und nein. Es ist interessant. Ich arbeite jetzt bei K15t, ich war früher Kunde von K15t, also habe ich das Team so kennengelernt. Und so habe ich auch die Dokumentation überhaupt erst kennengelernt. Bei meinem letzten Job haben sie mich beauftragt, dieses System namens Jira zu verwalten. Und ich sagte: „Ich weiß nicht, was das ist.“ Ich sagte ihnen: „Ich dachte, ich könnte es schaffen.“ Und ich habe es herausgefunden, es war dieses kleine Ding namens Jira On-Demand, das jetzt Jira Cloud ist. Und ich habe dem Unternehmen auch Confluence On-Demand vorgestellt. Und wow, ich habe Jira oft kaputt gemacht.
Zum Glück war es zu der Zeit nicht unternehmenskritisch, wir waren immer noch dabei, es wirklich herauszufinden. Aber erst durch die Dokumentation von Atlassian zu Jira habe ich wirklich gelernt: „Wow, diese Inhalte haben hier einen enormen Wert.“ Und dann entdeckte ich: „Okay, wie erstellt Atlassian ihre Dokumentation? Oh, sie machen das in Confluence. Sie schreiben es in Confluence. Sie verwenden diese Apps von K15t.“ Also fing ich an, diese Apps zu verwenden, und dann habe ich viel mit dem K15t-Kundensupport gesprochen, nur Fragen und wie fange ich damit an?
Und wir bieten unseren Support auch intern an, also ist es wirklich großartig. Also vielleicht habe ich es als Kunde zu oft genutzt, ich weiß nicht. Ich sollte einige meiner Kollegen fragen, ob sie genug von mir haben. Aber der Vorteil lag auf der Hand, denn sie sagten mir: „Oh, hier ist die Dokumentation dazu. Und hier ist die Antwort auf diese Frage oder hier sind die Überlegungen, die Sie berücksichtigen sollten.“ Und tatsächlich schauen wir uns jetzt einige unserer Teams wirklich an, vor allem nach den Funktionen, die sehr robust sind, und die Leute haben Fragen.
Es ist also wie, wie können wir ihnen helfen, sich selbst zu helfen? Und diese Ressourcen bereitzustellen ist eine Sache, sicherzustellen, dass Google sie finden kann, nun ja, eine andere. Aber das ist eine wirklich wichtige Sache, vor allem, weil als Produktteam, wenn Ihre Nutzerbasis wächst, auch Ihr Bedarf an Unterstützung steigt. Es ist nur... Ich will nicht sagen, dass es exponentiell ist, aber es entspricht einander. Eine der Möglichkeiten, dem entgegenzuwirken, besteht darin, sicherzustellen, dass Sie ein gutes Design haben, damit Ihr Produkt einfach zu bedienen ist. Und zum anderen benötigen Sie gute Inhalte rund um das gesamte Erlebnis, damit Sie nicht immer mehr Support-Mitarbeiter einstellen müssen.
Oder Ihre Support-Mitarbeiter können sich spezialisieren und sich wirklich auf diese tief verwurzelten Probleme konzentrieren, und dann sollte die Dokumentation beim Rest helfen. Aber das Geheimrezept ist knifflig. Es ist schwierig, den perfekten Inhalt zu schreiben, um die Fälle abzuwehren. Das ist jedermanns Traum.
Henri Seymour:
Auch wenn es einfach nicht alle sind, aber einige der häufigsten Anwendungsfälle werden langsam vom Support abgelenkt, weil die Leute Self-Service machen können. Das macht einen Unterschied. Und ich verstehe auch die Idee der Jira-Dokumentation wirklich. Easy Agile funktioniert auf Jira und es ist... Jira ist derzeit ein unglaublich kompliziertes Produkt, und ich kann mir vorstellen, dass es wahrscheinlich auch kompliziert war, als es Jira On-Demand war. Weil es so kompliziert und detailliert ist, gibt es keine Möglichkeit, es einem Benutzer ohne diese Dokumentation leicht verständlich zu machen. Daran führt kein Weg vorbei.
Matt Reiner:Ja. Ich denke, es sollte einen Club für die Leute geben, die in Jira zu oft Workflows kaputt gemacht haben. Aber ja, ich meine, die Dokumentation hat mich viele Male gerettet und ich müsste eine... Nun, zu der Zeit war es eine HipChat-Nachricht. Möge es in Frieden ruhen und ich müsste sagen: „Ich habe Jira kaputt gemacht, gib mir eine Minute. Ich muss etwas lesen gehen.“ Nicht so, wie du Jira lernen möchtest, aber es ist eine Option.
Henri Seymour:
Ist es. Manchmal lernt man Dinge, indem man Dinge kaputt macht. Das ist...
Matt Reiner:
Das ist richtig.
Henri Seymour:
Scheint wirklich meine bisherige Erfahrung mit Software zu sein. Du versuchst, die Dinge kaputt zu machen, die die Leute gerade nicht benutzen, und das ist ungefähr alles, was du tun kannst.
Matt Reiner:
Exakt.
Henri Seymour:
Also hat K15t kürzlich Rock the Docs veröffentlicht. Kannst du uns etwas mehr über dieses Projekt erzählen?
Matt Reiner:
Ja. Rock the Docs, eigentlich ging das aus einer Menge Informationen hervor, die ich von K15t bekommen habe. Kundensupport, die ich von der K15t-Dokumentation erhalten habe, habe ich von der Atlassian-Dokumentation erhalten. Und dann einige Dinge, die ich selbst herausgefunden habe, oder einige meiner Kollegen bei K15t haben es getan. Im Grunde genommen, was sind die besten Methoden, um wirklich gute Inhalte in Confluence zu erstellen? Und es begann wirklich mit einer Sammlung von Anleitungen zur Erstellung von Inhalten zur technischen Dokumentation. Es ist darauf ausgerichtet, ein öffentliches Hilfecenter einzurichten, aber in Wirklichkeit ist es für alle Arten von Inhalten, die Sie möchten, wie immergrüne, langjährige Inhalte, um Menschen helfen zu können.
Wir haben also zunächst über alle möglichen Dinge gesprochen, wie die Strukturierung deiner Inhalte, die Wiederverwendung von Inhalten und die Verwaltung mehrerer Sprachen, was in Confluence schwierig sein kann. Zusammenarbeit, Veröffentlichung deiner Inhalte auf die eine oder andere Weise außerhalb von Confluence, Verwaltung von Versionen dieser Inhalte. Das ist also der Anfang. Und dann bekamen wir eine Menge positiver Reaktionen und hatten allgemeinere Fragen wie: „Okay, aber was sind die besten Möglichkeiten, Feedback in Confluence zu erhalten?“ Oder: „Wie erstelle ich eine Vorlage oder eine gute Vorlage oder wie erstelle ich ein gutes Diagramm in Confluence?“
Deshalb haben wir diesen Inhalt erweitert, sodass er sich auf alle möglichen allgemeinen Confluence-Dinge konzentriert. Weil wir festgestellt haben, dass es da draußen eine Menge Informationen darüber gibt, wie man etwas macht. Die Atlassian-Dokumentation war wirklich hilfreich, aber es gab nicht so viele. Ich frage mich: „Warum würdest du das tun? Und warum würdest du das auf diese spezielle Art machen?“ Und wir arbeiten jetzt seit über 10 Jahren mit Confluence zusammen. Wie ich schon sagte, ich bin seit den ersten Tagen mit den krassen Wolken bei Confluence. Es ist so schnell gewachsen, es ist wunderschön.
Aber wir wissen einfach, dass wir eine Menge Dinge mit Confluence gemacht haben, also war es ein echtes Privileg, das beide in Form dieser schriftlichen Anleitungen zu teilen. Und dann haben wir vor Kurzem auch damit begonnen, eine Serie auf unserem YouTube-Kanal zu veröffentlichen, in der es um die Best Practices von Confluence geht.Henri Seymour:
Das ist großartig. Es ist wirklich interessant zu hören, dass das als kleineres Projekt begann, als es sich herausstellte, weil man den Wert und den Nutzen darin sehen konnte. Wir haben jetzt ein paar Mal über Confluence gesprochen und K15t entwickelt Apps, die Confluence als Dokumentationsquelle verwenden. Kannst du uns mehr darüber erzählen, warum Confluence für die Erstellung technischer Dokumentationen nützlich ist? Welche Tools und Herangehensweisen machen es in diesem Zusammenhang nützlich?
Matt Reiner:
Ja. Confluence ist von Natur aus offen, und so werden technische Schreibwerkzeuge nicht gebaut. Tatsächlich erinnere ich mich an das erste Mal, als ich zu einer Konferenz für technisches Schreiben ging und mich jemand fragte: „Oh, welches Tool verwendest du?“ Das ist quasi das, worüber die Leute in der technischen Kommunikation sprechen, weil wir in dieser Hinsicht alle Nerds sind. Und ich dachte: „Oh, ich mache das in Confluence.“ Und danach wollten sie nicht wirklich mit mir sprechen, weil sie nicht dachten, dass ich ein ernsthafter Tech-Autor bin. Und ich sagte: „Oh nein, nein, nein, nein, das passiert alles.“
Zu diesem Zeitpunkt existierte Rock the Docs noch nicht. Also konnte ich nicht sagen: „Geh rüber und sieh, wie es funktioniert.“ Aber der größte Unterschied ist, dass die meisten technischen Schreibwerkzeuge einfach komplett gesperrt sind. Sie haben zwei Lizenzen für Ihre beiden Personen, die ausgebildete professionelle technische Korrektoren sind, und dann für alle anderen, es gibt keinen Zugriff. Du berührst es nicht. Vielleicht schicken Ihnen Ihre technischen Redakteure ein PDF und Sie müssen den gottschrecklichen Prozess durchlaufen, ein PDF zu markieren, um ihnen mitzuteilen, was sie korrigieren müssen. Oder ich habe von Teams gehört, die den Inhalt ausdrucken und Leute angeben, was geändert werden muss.
Die Überprüfungsverfahren sind einfach nicht von dieser Welt verrückt. Und diese Tools passen nicht besonders gut zu agilen Prozessen, weil es so ist, du baust das Ding hier drüben und dann sind hier die beiden technischen Autoren in ihrem separaten Tool. Und irgendwann werden wir sagen: „Okay, das Ding ist fertig. Würdest du darüber schreiben?“ Bei Confluence besteht der Vorteil der Verwendung von Confluence also darin, dass es für jeden im Team und sogar für Personen außerhalb des Teams zugänglich ist. Und das ist unglaublich von einem Beamten, weil wir bei Agile gesehen haben, aber wir sehen auch in diesem Bereich der technischen Kommunikation und des Informationsdesigns, dass Teams immer weniger nach Fachkräften suchen, die ausgebildete technische Redakteure sind.
Was ein Oxymoron ist, weil die Hälfte von uns, wir haben keinen Abschluss in technischem Schreiben, wir sind aus dem einen oder anderen Grund darauf reingefallen. Aber jetzt beginnen die Teams zu erkennen: „Hey, ich kann Codeentwickler und Informationsentwickler werden. Ich schreibe vielleicht nicht den letzten schriftlichen Inhalt, der von unseren Kunden gesehen wird, aber vielleicht schreibe ich den ersten Entwurf.“ Confluence macht das wirklich allen zugänglich. Und gerade bei Erwähnungen und Inline-Kommentaren sind die Überprüfungsprozesse einfach so schnell.
Eigentlich war der Grund, warum ich bei meinem letzten Job zu Confluence gewechselt bin, dass mein Produktmanager mir drohte und sagte: „Ich werde kein weiteres PDF mit Markups versehen. Geh und finde ein gutes Tool, mit dem wir alle arbeiten wollen.“ Und dort sind wir auf Confluence gelandet. Es geht darum, das gesamte Team in den Schreibprozess einzubeziehen, anstatt dass es sich um eine separate Sache handelt. Denn wenn es eine separate Sache ist, verlieren wir den Überblick. Und beim Inhalt vergessen wir, wie wichtig er für unser Produkt ist, für den Kundenlebenszyklus, für... Gott segne den Kundensupport, der diese Inhalte wirklich, wirklich braucht, um gut und korrekt zu sein.
Und es muss von den echten Experten gesehen werden, die bestätigen: „Ja, okay, das ist richtig. Das wird den Leuten tatsächlich zeigen, wie unser Produkt funktioniert.“ Und Confluence ist quasi das Herzstück davon.
Henri Seymour:Nein, es ist toll zu hören, wie das alles zusammenkommt, um die Dokumentation als Team zu erstellen. Können Sie näher auf die verschiedenen Rollen eingehen, insbesondere in der Softwareentwicklung, und auf die verschiedenen Rollen, in denen Sie sich an Ihrem Dokumentationsprozess beteiligen möchten? Wir arbeiten hier bei Easy Agile daran, unsere spezifischen App-Teams aufzubauen, da wir derzeit wachsen.
Matt Reiner:
Ja. Das ist so eine gute Frage. Nun, was...
Henri Seymour:
Und wie integriert man... Entschuldigung, das bezieht sich eher auf meine Frage. Wie integrieren Sie diesen technischen Schreibprozess in die Arbeit eines agilen Softwareentwicklungsteams?
Matt Reiner:
Nun, zunächst müssen die Prioritäten überdacht werden, weil die meisten Teams sagen: „Dokumentation hier unten, Testen und dann alles andere oben“. Im Allgemeinen sollten diese beiden Dinge also nach oben verschoben werden. Und eigentlich ist der Inhalt rund um unser Produkt... Ich möchte nicht traumatisch klingen, aber wenn wir keine Informationen haben, haben wir kein Produkt. Mir ist egal, wie viel Code du schreibst. Wenn wir es den Leuten nicht erklären, wenn wir keinen guten UI-Text haben, wenn wir keine gute In-App-Hilfe haben, existiert er nicht. Es ist kein nützliches Tool, es ist nur eine Reihe von mathematischen Methoden, mit denen Menschen nicht interagieren können.
Inhalte sind also unerlässlich, daher ist es wirklich wichtig, dass wir sie so weit bringen, dass jeder im Team erkennt, dass das Inhaltserlebnis, das unsere Nutzer haben, das Produkterlebnis ist, das sie haben. Es muss also Teil des Produktentwicklungsprozesses sein. Also dann der nächste Schritt, von dem ich weiß, dass Sie über Teamstruktur sprechen, aber der nächste Schritt ist, dass wirklich jeder im Team wissen muss, dass er ein Autor ist, und zwar ein guter Autor. Und das ist wichtig, weil viele Leute das noch nie gehört haben. Sie haben nie gehört, dass sie ein guter Schriftsteller sind, und sie haben wahrscheinlich nie gehört, dass sie Schriftsteller sind.
Ich erinnere mich an die Universität, mein Schreibunterricht waren die Dinge, auf die ich nicht geachtet habe. Ich habe Mathematik und Java-Programmierung und Statistik gemacht. Sogar das schien mir wichtiger zu sein, nicht der Schreibunterricht. Und dann stellt sich heraus, dass tatsächlich jeder schreiben muss. Wir schreiben alle. Es ist also wirklich wichtig zu wissen, dass das eine Rolle ist, die jeder ausfüllt. Und wenn es dann um die eigentliche Teamstruktur geht, braucht man Leute, die sozusagen bereit sind, die Streams zu überqueren. Wenn Sie jemanden hinzuziehen, der sich auf Testtechnik konzentriert, muss dieser erkennen, dass die Testpläne, die er schreibt, einer Menge Benutzerdokumentationen, die geschrieben werden müssen, sehr ähnlich sind.
Sie schreiben Aufgabenthemen oder Aufgabenanweisungen, tun Sie dies, tun Sie dies, tun Sie das immer und immer wieder. Das ist Dokumentation. Sie könnten auf diese Weise beitragen. Ingenieure könnten, wie ich bereits erwähnt habe, die erste Kopie vieler sogenannter Konzeptthemen verfassen. Also Bereiche der Dokumentation, in denen Sie Konzepte erklären, weil sie bereits wissen, was diese Konzepte sind. Wenn Sie sich in der Tat die Wurzeln vieler agiler Entwicklungsteams ansehen, verwenden sie Epen, User Stories und Akzeptanzkriterien. Und all diese lassen sich perfekt in die Dokumentation integrieren, die Sie für das neue Feature, an dem Sie arbeiten, oder das Sie verbessern, erstellen mussten.
Es ist also wirklich wichtig, dass jeder erkennt, dass wir alle bereits Dokumentationen erstellen, damit wir einen Beitrag leisten können. Und dann möchten Sie natürlich wirklich mindestens einen englischen Muttersprachler haben. Vielleicht kein Muttersprachler, aber jemand, der sich in seinem Englisch oder in der Sprache, in der Sie schreiben, sicher fühlt. Englisch lässt sich in der Regel am billigsten in andere Sprachen übersetzen, also ist es das, wofür sich die Leute oft entscheiden. Aber diese Person ist die Person, die alles, was jeder geschrieben hat, nimmt und es auf den richtigen Stil und Ton bringt. Und dann bringt er es raus. Das ist es, was wir als erfolgreich ansehen.
Wie unsere Teams im Moment haben wir keine seriösen Tech-Autoren. Wir haben Produktmanager, die schreiben. Wir haben Produktvermarkter, die schreiben. Wir haben Ingenieure, die schreiben. Einige der besten Dokumentationen, die ich je gelesen habe, stammen von einem unserer deutschsprachigen Ingenieure. Ich dachte: „Peter, das ist eine tolle Anleitung. Du musst dieses Java verlassen und Englisch lernen, Mann. Es ist großartig. Es ist großartig.“ Also hat er ein paar gemacht, was ich wirklich liebe. Aber ja, es geht darum, aus den typischen Rollen herauszuspringen und zu erkennen, dass wir das alles sowieso alle dokumentieren.
Henri Seymour:
Ich liebe den Fokus, besonders mit Ihrem deutschsprachigen Kollegen. Der Fokus liegt nicht nur darauf, dass Sie die Dokumentation schreiben müssen, weil Sie wissen, wie das Produkt funktioniert, und das brauchen wir schriftlich. Es ist, Sie sind in der Lage, die Dokumentation zu schreiben, Sie können das tun. Sie haben diese zusätzliche Sicherheitsbarriere gegenüber jemandem, der die Sprachkenntnisse hat, dass er es am Ende massieren und bearbeiten wird.
Also, bevor es irgendwohin kommt, wird alles, was Sie tun, herausgefiltert, wenn es nicht funktioniert. Sie benötigen jedoch keinen speziellen technischen Hintergrund, um die Dokumente zu schreiben.
Matt Reiner:
Nein, absolut nicht. Tatsächlich gibt es eine ganze Gemeinschaft von was... Sie nennen sich selbst Dokumentarfilmer und heißen Write the Docs. Und diese ganze Community, diese ganze Gruppe konzentriert sich darauf, es spielt keine Rolle, was Sie tun, es ist wichtig, dass es Ihnen wichtig ist, die Dokumente zu schreiben und zum Inhalt beizutragen. Und das war, glaube ich, ein großer Wandel in der Branche, wo die Leute dachten, wir wären getrennt. Aber jetzt ist es so: „Nein, nein, nein, wir sind alle in der Lage, das zu tun.“ Und sobald wir die Beiträge respektieren können, die jeder von uns leisten kann.
Und dann habe ich auch den Schutz, dass jemand anderes seine Augen darauf richten wird, was selbst in meinem Schreiben, ich sage: „Ich schicke es nicht gerne raus, bis es jemand anderes gesehen hat.“ Weil ich ständig Rechtschreib- und Tippfehler mache. Ich möchte wirklich, dass sich ein anderer Kollege das ansieht. Auch wenn sie kein Englisch als Muttersprache haben, weil sie meine Tippfehler ziemlich oft erwischen. Dieses Gefühl der Zusammengehörigkeit ist genauso, wie wir uns fühlen, wenn wir ein Projekt oder ein Produkt versenden.
Egal, ob Sie die Tests dafür durchgeführt haben, oder ob Sie den Code dafür geschrieben haben oder ob Sie das Produktmarketing dafür gemacht haben. Es ist wie: „Es ist unser Baby. Lass es uns rausschicken und sehen, was passiert.“ Der Inhalt ist genauso.
Henri Seymour:
Ja, Teil meiner täglichen Rolle und [unhörbar 00:28:03]... Wir haben kein QA-Team, das von den Entwicklern getrennt ist. Unsere Entwickler überprüfen auch unseren Code und es entsteht das Gefühl: „Ich habe dieses Ding geschrieben, aber ich habe ein oder zwei andere Leute, die es verfeinert haben und dafür gesorgt haben, dass die Qualität gut genug ist. Sie haben diesen frischen Blick, also werden sie die Rechtschreibfehler sehen, sie werden die kleinen kleinen Fehler erkennen, die ich mir einfach zu lange angesehen habe, um sie noch zu bemerken.“
Ich habe festgestellt, dass der Prozess des Schreibens von Dokumentationen einige Parallelen hat, wie zum Beispiel: „Hier ist mein Ding. Ich hätte gerne Feedback dazu, bevor es in die reale Welt geht.“
Matt Reiner:
Ja.
Henri Seymour:
Das ist großartig.
Matt Reiner:
Ja, absolut. Ja.
Henri Seymour:
In Ordnung. Können Sie etwas über den Unterschied zwischen der kundenorientierten Dokumentation, die wir bisher hauptsächlich besprochen haben, und der internen Dokumentation sprechen?
Matt Reiner:
Ja. Es gibt einige Unterschiede und es gibt einige große Ähnlichkeiten. Also das ist sehr... Das klingt sehr technisch und hässlich. Der Begriff Informationsarchitektur ist wirklich wichtig für jede Art von Inhalten, intern und extern. Und das ist wirklich so, wenn Sie ein Entwickler sind, kennen Sie sich mit XML aus, Sie sind damit vertraut, Dinge auf diese Weise zu strukturieren. Unsere Inhalte müssen auf die gleiche Weise funktionieren. Und das gilt für die interne und externe Dokumentation. Also, viele der Dinge, die sie als Autoren verwenden, wenn sie eine Seite oder einen Artikel in der Zeitung schreiben, verwenden sie den Pyramidenansatz, bei dem sie die großen Informationen an die Spitze stellen. Und dann konzentrieren sie sich langsam auf das Thema und geben immer mehr Informationen darüber.
Sie sollten jedoch sicherstellen, dass jemand, der nur den ersten Absatz liest, eine ungefähre Vorstellung davon bekommt, um welche Informationen es sich handelt. Und das ist wirklich wichtig für erfolgreiche Confluence-Seiten und -Bereiche. Die Leute sollten in der Lage sein, auf der obersten Ebene des Bereichs zu beginnen, zu verstehen, worum es in dem Bereich geht, und dann in der Lage sein, auf der Seite selbst zu dem zu navigieren, worüber sie wirklich lernen möchten. Was dann aus Überschriften, Unterüberschriften und Aufzählungspunkten bestehen sollte, um diese Informationen einfach zu verbreiten und aufzuschlüsseln. Weil jeder überfliegt.
Wir brauchen, dass unsere Inhalte überflogen werden können, unsere Räume müssen überflogen werden können. Und diese Art von Inhalten macht auch die Confluence-Suche glücklich, insbesondere die neue Confluence Cloud-Suche, die stark verbessert wurde. Dazu gibt es eine ganz neue elastische Suchbasis, die gerade optimiert wird. Aber es ist glücklich, es ist genau wie bei Google, wenn wir unsere Inhalte so strukturieren. Wenn Sie also eine Seite haben, die nur aus Text besteht, ohne Überschriften, die Sie nicht in Seiten oder gar Leerzeichen aufteilen, wird niemand damit zufrieden sein.
Die Bots werden damit nicht zufrieden sein, die Leute, die lesen, werden damit nicht zufrieden sein. Es erfordert also ein bisschen Arbeit, die Struktur unserer Inhalte zu strukturieren und aufzubrechen. Es ist wahrscheinlich alles in Ordnung, solange es aktuell ist, aber es ist wirklich wichtig, dass wir darüber nachdenken, wie wir das in Confluence strukturieren, damit die Leute es finden und die Leute es überfliegen können. Und genau das scheint viele interne Confluence-Instanzen zu plagen, denn viele... Vielleicht konzentriert sich das Team nicht so sehr darauf.
Es ist wie: „Oh, unser externes Hilfecenter, das aus diesem Bereich hier kommt, das ist in Ordnung. Unser Teamraum, großes Durcheinander, totaler Reifenbrand.“ Und niemand kümmert sich darum, weil sie glauben zu wissen, wo alles ist. Aber dann fängst du an, darüber nachzudenken: „Okay, aber was ist mit dem neuen Teammitglied? Wie finden sie etwas?“ Oder: „Was ist mit dem Teammitglied, das seit sechs Wochen wegen Vaterschaftsurlaubs weg ist? Werden sie sich daran erinnern, wo alles ist, oder wissen sie, wo all die neuen Sachen sind?
Was ist mit Menschen mit Behinderungen? Wird es für sie viel schwieriger sein, zu den Informationen zu navigieren, die sie benötigen? Weil sie mit einem Screenreader arbeiten und versuchen, durch eine Textwand zu gehen. Sie benötigen Überschriften, ein Screenreader verlässt sich auf diese Überschriften und Titel.“ Es gibt also einfach so viele Überlegungen, die die Unternehmensführung wirklich verstehen muss. Nur weil Sie einen Prozess haben, um etwas zu tun, oder die Informationen irgendwo sind, heißt das nicht, dass Sie kein großes Informationsproblem haben. Und all deine Inhalte in Confluence zu pflegen und dann gut zu pflegen.Dies ermöglicht es den Menschen, die Frustration zu vermeiden, nach Informationen zu suchen, Informationen zu verlieren, Informationen neu lernen oder neu schreiben zu müssen. Ich habe in zu vielen Unternehmen gearbeitet, in denen Informationen einfach überall gesiebt werden. Ich möchte sie nicht einmal Silos nennen, weil auch niemand mehr weiß, wo sich die Dinge befinden. Das ist es, was Confluence ausmacht, und darauf kommt es sowohl bei internen als auch bei externen Inhalten an.
Henri Seymour:
Das ist eine großartige Perspektive. Und ich kann die Silos sehen, es ist wirklich mehr... Nur ein großer Stapel, du kannst nichts finden. Ich war...
Matt Reiner:
Exakt.
Henri Seymour:
... seit mehr als der Hälfte seines Lebens bei Easy Agile und ich habe das Gefühl: „Oh, ich weiß, ich habe das irgendwo aufgeschrieben. Ich weiß, dass ich das irgendwo aufgeschrieben gesehen habe.“ Und wir machen es uns zur Gewohnheit, vor allem, weil wir immer mehr Leute einstellen. Jedes Mal, wenn jemand ein Onboarding durchläuft, wird er sich die gesamte Dokumentation ohne vorherige Hintergrundinformationen ansehen. Und wir möchten speziell ihr Feedback dazu hören. Denn wenn es für sie funktioniert, dann ist das die Dokumentation, die wir für sie und für alle nach ihnen brauchen, und für alle, die schon hier sind.
Vor allem bin ich jetzt seit fast drei Jahren bei Easy Agile und ich habe gesehen, wie es von acht Mitarbeitern auf jetzt, glaube ich, über 20 Jahre gewachsen ist. Ende des Jahres werden wir in die 30er Jahre übergehen.
Matt Reiner:
Beeindruckend.
Henri Seymour:
Das Wachstum der Informationen, die wir in unserer internen Dokumentation haben, und ich bin mir sicher, dass dies mit dem Wachstum der Produktdokumentation für ein Produkt einhergehen würde, das seit drei bis fünf Jahren expandiert. Wie verwaltest du die Dokumentation und die Confluence-Bereiche, wenn das Team und das Unternehmen wachsen und du einfach immer mehr Seiten daraus entwickelst?
Matt Reiner:
Das ist die Frage seit den Anfängen des Universums oder zumindest seit den Anfängen von Confluence, was ist der Unterschied? Die größte Sache ist die Teamverantwortung, also zu wissen, dass dies unser Raum ist, das ist unser Inhalt. Und zwar nicht auf territoriale Weise, aber das liegt in unserer Verantwortung. So wie wir über unseren Planeten nachdenken sollten, sollten wir auch über unsere Inhalte nachdenken und dafür sorgen, dass sie gepflegt und gepflegt, aktuell und korrekt sind. Und dann, wenn sich die Dinge ändern.
Wir haben zum Beispiel ein Produkt namens Scroll Viewport, mit dem du Inhalte von Confluence in einem öffentlichen Gesundheitszentrum veröffentlichen kannst, was wirklich, wirklich cool ist. Damit hatten wir also eine Server- und Rechenzentrumsversion. Das haben wir schon seit geraumer Zeit. Das war es, was ich genutzt habe. Und dann haben wir uns auf den Weg gemacht, eine Cloud-Version zu entwickeln, und die Cloud erfordert eine ganze Reihe neuer Infrastrukturen, was viel Spaß macht und sehr herausfordernd ist, aber es ist eine ganz andere Sache.
Es ist nicht so, dass man einfach den Servercode hochziehen und ihn einfach in die Cloud ziehen kann, worum ich sie als Benutzer jahrelang gebeten habe: „Warum ist das nicht in der Cloud?“ Jetzt weiß ich warum. Also haben wir ein neues Team zusammengestellt, das mit Scroll Viewport on Cloud begann. Und anfangs war es nur ein sehr schlampiges Projekt. Und ich erinnere mich an die erste Seite, auf der wir da oben waren wie: „Whoa, sieh dir diese Seite an, die wir veröffentlicht haben.“ Und von da an ging es weiter. Aber irgendwann mussten wir die beiden Teams wieder zusammenbringen. Und was wir einfach hätten sagen können: „Oh, dieser alte Viewport-Raum, was auch immer. Wir lassen es einfach da und machen dann einfach mit dem neuen weiter.“
Aber stattdessen nahm sich das Team Zeit und brachte die beiden Bereiche zusammen und ging die alten Inhalte im Viewport Server- und Rechenzentrumsbereich wirklich durch, um zu sagen: „Ist das alles noch relevant? Brauchen wir das immer noch?“ Es wurde also auf so erstaunliche Weise neu angeordnet. Einige unserer Teams sind wirklich gut darin geworden, diese Räume so einzurichten, dass ich reinkommen kann. Weil ich mit all unseren Teams zusammenarbeite, geh einfach rein und finde, was ich brauche, auch wenn ich nicht täglich in ihnen arbeite. Ich bin einfach so froh, ich bin so stolz auf das Team, dass es diesen Raum nicht einfach irgendwo schwinden lässt oder Angst hat, Inhalte zu löschen oder zu archivieren, was bei vielen Leuten der Fall ist.
Es ist wie: „Nein, was ist, wenn wir etwas verlieren?“ Es ist wie: „Nein, nein, nein, das haben wir hinter uns gelassen. Wir müssen es wirklich löschen.“ Das ist die Art von Einstellung, die wir brauchen: Unsere Teams teilen sich auf, erweitern und wachsen, und wir müssen uns dieser Inhalte bewusst sein. Denn auch hier gilt: Denkt an die neue Person, denkt an die Person, die etwas Neues lernt. Denke an die Person, die vielleicht eine Behinderung hat und versucht, die Inhalte zu bekommen, die sie braucht. Sie haben einfach nicht den Hintergrund, den Sie haben. Sie sind die Hälfte ihres Lebens in der Firma und wissen, wie man den Gedankenstapel durchwühlt, um genau das herauszuholen, was man will, aber sie nicht.
Henri Seymour:
Ja, und ich möchte nicht die Person sein, die sie jedes Mal fragen müssen, wenn sie Informationen benötigen: „Hey, kannst du das für mich finden?“ Nein, nein. Ich möchte ein System aufbauen, das bedeutet, dass ich nicht ständig dieselben Fragen beantworten muss. Das ist einer der Gründe, warum ich seitdem so viel interne Dokumentation mache [unhörbar 00:37:36]. Ich habe diese Frage einmal beantwortet, das reicht.
Matt Reiner:
Ja. Das ist eine wirklich gute Möglichkeit, alle Mitwirkenden an der Dokumentation zu motivieren. „Hey, weißt du, wie du diesen Teil unserer App einmal geschrieben hast und dann haben dich alle gefragt, wie er seitdem funktioniert? Dokumentiere es einfach einmal und ich verspreche, dass du es nie wieder beantworten kannst.“ Genau das ist eine gute Motivation.
Henri Seymour:
Ist es. Außerdem haben wir ein Team für Support-Modelle, also arbeite ich an den Storemaps und Personas, dem Produktentwicklungsteam. Und das ist dasselbe Team, das alle Support-Anfragen zu Storymaps und Personas erhält. Also ja, je besser wir das Produkt machen, desto besser machen wir die Dokumentation, desto weniger Zeit verbringen wir jeden Morgen damit. Und je mehr wir zu unseren regulären Jobs zurückkehren können.
Matt Reiner:
Exakt.
Henri Seymour:
Es war großartig, um uns dabei zu helfen, mit den Kunden in Kontakt zu bleiben und zu erfahren, was sie tun und welche Informationen sie benötigen, wenn sie unser Produkt verwenden. Du hast erwähnt, dass es zwar notwendig, aber wertvoll ist, von Zeit zu Zeit archivbasierte Dinge, Seiten in Confluence, zu löschen. Wenn du dir eine Seite ansiehst und dich fragst, ob es Zeit ist, sie zu öffnen, welche Art von Fragen stellst du dir?
Matt Reiner:
Nun, eine tolle Idee ist wie, sieh dir das Datum der letzten Änderung auf dieser Seite an. Das ist im Allgemeinen ein ziemlich gutes Zeichen für so etwas wie: „Schauen die Leute es sich überhaupt an?“ Wenn Sie Cloud Premium und höher nutzen, können Sie sich sogar auf jeder Seite einige großartige Kennzahlen ansehen, um zu sehen, wer sich das Ding ansieht? Ist das wertvoll? Wie sind die Aussichten? Genauso, wie Sie sich Ihre externe Website ansehen würden, um zu sehen, ob Ihre Inhalte wertvoll oder effektiv sind. Aber in der Regel haben wir eine Menge Trümmer übrig, die von der Produktentwicklung oder Teamaktivitäten übrig geblieben sind.
Wenn Sie beispielsweise im Marketing tätig sind und eine Kampagne von vor drei Jahren haben, benötigen Sie dann wirklich all diese detaillierten Seiten? Vielleicht behalten Sie die gesamte Kampagnenseite bei, vielleicht ist das nützlich, aber brauchen Sie wirklich alles? Wenn du gerne testest, brauchst du wirklich jeden Testplan, den du jemals erstellt hast? Wenn Sie im Rechtsteam sind, möchten Sie wirklich Ihre rechtlichen Bedingungen von vor 10 Jahren? Vielleicht, vielleicht, bin ich nicht in der Rechtsabteilung. Aber oft haben wir diese Angst vor, es ist wie Angst vor fehlenden Inhalten.
Es ist wie: „Oh nein, wenn ich das loswerde, werde ich es nicht haben.“ Aber Informationen, genau wie Sprache, genau wie die Art und Weise, wie wir denken, genau wie die Art und Weise, wie unsere Teams wachsen, sie ändern sich. Und deshalb müssen wir uns dessen bewusst sein. Da wir uns als Team verändern, sollten Sie damit rechnen, dass sich unsere Inhalte ändern. Und ein Teil davon ist, das alte Zeug loszuwerden. Es lohnt sich also immer. Wenn du es in Frage stellst, frag einen anderen Fachexperten und sage: „Hey, ich bin mir ziemlich sicher, dass wir das nicht mehr brauchen, oder wir sollten es überarbeiten. Was denkst du?“ Aber wenn niemand Bedenken hat, solltest du es wahrscheinlich löschen.
Henri Seymour:
Nein, das ist großartig. Ich bin ein großer Fan von Entrümpeln, auch von digitalem Entrümpeln. Es ist, ich möchte, dass die Leute Sachen finden und je weniger Stapel es gibt, desto einfacher wird es sein.
Matt Reiner:
Ja. Weil schlechte Informationen irgendwie weniger hilfreich sind als keine Informationen.
Henri Seymour:
Ja. Es ist, als würden sie auf eine Frage stoßen und sie sagen: „Oh, ich habe es auf diese Weise versucht.“ Ich sage: „Oh, dieser Weg funktioniert nicht mehr. Du wirst tun müssen... Wo hast du das aufgeschrieben gefunden? Ich werde auf dem Laufenden bleiben.“ Es ist...
Matt Reiner:
Ja.
Henri Seymour:
... neue Leute, die Sachen machen. Der beste Weg, um zu verstehen, wo Ihre Dokumentation ins Stocken gerät. Es ist genauso, als ob Sie nie verstehen werden, wie Ihre Produktdokumentation und Ihr Produkt selbst Ihre Benutzer im Stich lassen, bis sie zu Ihnen kommen und Ihnen sagen: „Warum kann ich das nicht tun?“
Matt Reiner:
Ja. Ja. Ja, diese Fähigkeit, jemanden neu in Ihr Team zu holen, ist so unglaublich. Und es ist fast schwierig, am ersten Tag des Onboardings zu sagen: „Du hast frische Augen, bitte nutze sie. Das wird als Inline-Kommentar bezeichnet, bitte platzieren Sie ihn überall.“ Ich erinnere mich, dass ich unser Mitarbeiterhandbuch für die Personalabteilung durchgesehen habe, das wir kurz vor meinem Beitritt gerade erstellt hatten. Und ich erinnere mich, dass sie mir sagten: „Falls es irgendwelche Fragen gibt, hat uns at erwähnt.“ Und ich hatte wirklich Angst davor. Aber wir haben viele Dinge korrigiert.
Zum Beispiel haben wir erwähnt, dass Sie diese Dinge tun auf... Wie wurde es nach HipChat genannt? Das Produkt, das so schnell lebte und starb.
Henri Seymour:
Ich glaube, den habe ich verpasst.
Matt Reiner:
Oh, die, die Atlassian gemacht und dann an Slack verkauft hat.
Henri Seymour:
Nun, wo fange ich überhaupt damit an?
Matt Reiner:
Wie geht es mir... Es war eine tolle App, sie hat mir sehr gut gefallen. Aber wir haben im Mitarbeiterhandbuch erwähnt, dass wir das verwenden sollten. Und ich sage: „Oh, ich glaube, wir verwenden jetzt Slack, wir sollten diesen Inhalt aktualisieren.“ Das sind Dinge, die die Personalabteilung niemals durchgehen und auffangen wird, aber deine neuen Mitarbeiter können das tun. Neue Mitarbeiter sind der beste Weg, um Ihnen zu sagen, ob Ihre Prozesse schlecht sind oder ob Ihre Inhalte besser sind. Vielleicht nicht schlecht, aber sie bringen etwas Neues ein. Deshalb haben wir sie ins Team aufgenommen. Und sie sollten vom ersten Tag an keine Angst haben, Fragen zu stellen oder Löcher in unseren bereits verkorksten oder gescheiterten Prozess zu bohren.
Henri Seymour:
Ja. Und ich kann den Vorteil der Tools in Confluence wirklich erkennen, wie dieser Inline-Kommentar. Auch wenn du nicht weißt, wie du diese Seite aktualisieren musst oder wie die neue Version aussehen soll. Es kommt gerade neu rein, du kannst sagen: „Oh, das ist komisch oder unvollständig, oder es könnte falsch sein.“ Es ist nur ein kleiner Kommentar. Du musst es nicht selbst ändern, sag einfach etwas. Hier ist eine Möglichkeit, sich zu äußern, ohne es selbst zu ändern. Und jemand, der es weiß, wird in der Lage sein, es für Sie zu ändern.
Ich habe mich gefreut, Sie über Informationsarchitektur sprechen zu hören. Das habe ich auch erst letztes Jahr kennengelernt. Haben Sie eine allgemeine Erklärung, was Informationsarchitektur ist und warum sie für die Dokumentation relevant ist?
Matt Reiner:
Oh, Informationsarchitektur ist, es gibt ganze Leute, Profis, deren gesamte Karriere reinkommt und einem hilft. Also ich gehöre nicht zu diesen Profis, ich spiele nur einen im Fernsehen. Im Wesentlichen zerlegt die Informationsarchitektur etwas, das eine Textwand wäre, in ein Informationsmuster, mit dem sich jeder Geist verbinden kann. Das ist das eigentliche und ultimative Ziel, und das beginnt damit, logische Teile aufzubrechen. Tatsächlich zerlegt man beim Schreiben rein technischer Texte den Inhalt in winzige, winzige Teile, oder einige technische Kommunikatoren sprechen von Informationatomen, wirklich winzigen Teilen.
Und wenn Sie das dann aufgeschlüsselt und gesagt haben: „Das sind separate Teile“, setzen Sie sie in einer Reihenfolge zusammen, die Sinn macht. Tatsächlich kannst du mit der Wiederverwendung von Inhalten in Confluence auch wirklich coole Sachen machen, indem du Include-Makros verwendest. Das neue Excerpt Include Macro ist in der Cloud sehr cool, weil du damit neue Sachen machen kannst. Aber es geht wirklich darum, all deine Inhalte auseinanderzunehmen und herauszufinden, in welcher Reihenfolge das alles abläuft? Was ist am wichtigsten? Was ist spezifischer? Was ist wichtig für alle? Was ist wichtig für nur wenige Menschen?
Und dann gehen Sie einfach nach unten, wie Sie es mit einer XML-Struktur oder einer anderen Art von Hierarchie tun würden, und ordnen Sie diese Informationen mithilfe Ihrer Leerzeichen, Ihrer Seiten, Ihrer Überschriften an. Und dann endlich Aufzählungszeichen und Absätze und so weiter.
Henri Seymour:
Danke, dass du das allgemein erklärt hast. Gibt es im Moment etwas, das Sie in Ihrer Arbeit erwähnen möchten, für das Sie die Leser interessieren würden?
Matt Reiner:
Ja, absolut. Ein großer neuer Aufwand für mich, weil ich wohl nur dieser Content Explorer bin. Ich mochte technische Inhalte, ich habe einige Marketinginhalte geschrieben. Ich habe angefangen zu sprechen, was mir Spaß macht. Ich durfte vor einem Live-Publikum sprechen, bevor... Nein, ich schätze ein paar, und dann ist die Welt aus gutem Grund zum Erliegen gekommen. Denn wenn man eine Menge Leute angreift, möchte man sichergehen, dass man sie nicht potenziell einem Risiko aussetzt. Ich habe also viel virtuell gesprochen.
Aber vor Kurzem habe ich erwähnt, dass wir an all diesen Best Practices für Rock the Docs gearbeitet haben. Deshalb haben wir diese Videoserie über die Best Practices von Confluence gestartet und es war sehr aufregend herauszufinden: „Okay, ich weiß also, wie man in Confluence ziemlich gute Inhalte erstellt, wie man diese Inhalte strukturiert. Können wir jetzt ein gutes Video machen?“ Und es stellt sich heraus, nein, zuerst nicht. Habe ein paar ziemlich schlechte gemacht oder solche, für deren Herstellung einfach viel zu viel Zeit in Anspruch genommen wurde. Und schließlich, wie Sie es bei jeder Art von Inhalten tun, haben wir endlich eine gute Struktur, einen guten Rhythmus. Und wir haben auch herausgefunden, über welche Dinge die Leute wirklich hören wollen?
Deshalb haben wir jetzt 16 davon auf unserem YouTube-Kanal entwickelt, die nur für Administratoren da sind, um sie mit deinen Nutzern zu teilen, die diese Fragen stellen. Oder vielleicht richten sie sich direkt an Nutzer, die einfach nur abonnieren und diese Dinge erhalten möchten. Aber es sind ungefähr acht Minuten mit genau so vielen Informationen, wie wir einpacken können und trotzdem gut lesbares Englisch sprechen. Und dann zeige einfach, wie macht man das in Confluence? Warum würdest du das in Confluence machen? Was sind die Dinge, die du in Confluence beachten solltest? Was sind die besten Möglichkeiten, Dinge in Confluence zu erledigen?
Wir haben auch gerade eine Reihe von Livestreams gestartet, bei denen wir versuchen, uns diese genauer anzusehen und dann die Leute live zuzuhören, Fragen zu stellen und Regie zu führen. Bisher waren diese wirklich großartig und wir planen, mehr davon zu tun. Je mehr Leute sich also darauf einlassen, desto mehr Richtung habt ihr alle, diesen Inhalten zu geben. Aber es waren neue Arten von Inhalten, und es ist aufregend zu sehen, okay, unsere gut geschriebenen Inhalte in Confluence kommen in einem neuen Format in die reale Welt. Das war cool und herausfordernd und lustig und gruselig zugleich.Henri Seymour:
Ja. Das klingt nach einem wirklich aufregenden Projekt. Rock the Docs wird audiovisuell. Und ich kann...
Matt Reiner:
Das ist richtig.
Henri Seymour:
... stell dir vor was... Bringen Sie die Nutzer dazu, Ihnen das iterative Feedback zu geben, über das wir am Anfang gesprochen haben. Also ist das den Daumen hoch wert? Haben Sie Kommentare? Was können wir noch tun? Und besonders bei dieser Art von Live-Stream-Webinaren erhalten Sie den direkten Kontakt zu Ihren Benutzern, sodass Sie herausfinden können, was sie benötigen. Das ist fantastisch. Mal sehen, ob ich die mitbringen kann. Easy Agile begann speziell Anfang dieses Jahres, Scroll Viewport für die Cloud zu verwenden.
Matt Reiner:
Oh, cool. Oh, cool.
Henri Seymour:
Das war also tatsächlich eine große Verbesserung für uns.
Matt Reiner:
Oh, gut. Ja. Mir gefällt einfach, was das Cloud-Team herausbringt. Es ist so aufregend und so ausgefeilt und es ist, als ob jedes Team diesen Dokumentationsbereich hat, und Viewport, damit kannst du es veröffentlichen und du denkst: „Ah, sieht so toll aus. Wir sind so stolz darauf.“ Du kannst es auf jedem Gerät lesen. Es ist einfach so, als ob es die Magie ist, die jeder will, aber kein Team hat Zeit. Unsere sehr wenigen Teams haben Zeit, es so gut aussehen zu lassen, also ist es schön, dass Viewport einfach die Schwerarbeit erledigt.
Henri Seymour:
Wir haben den Confluence-Bereich, wir haben die Dokumentation. Wir müssen keine Website darüber erstellen. Es ist nur: „Mach weiter, bitte lass diese Website Wirklichkeit werden. Hier ist, was wir darauf brauchen. Hier ist die Struktur.“ Und meine Güte, es sieht jetzt viel besser aus, auch nur ästhetisch, es sieht im Haus sehr gut aus.
Matt Reiner:
Ja. Und es ist schön zu wissen, dass ein Designer den Abstand zwischen den Navigationselementen überschaut hat, um zu entscheiden, wie weit sie voneinander entfernt sein sollten. Und als Autor kann ich einfach sagen, es muss mir egal sein. Mir muss das egal sein. Ich kann Confluence-Makros und so reinwerfen, und sie sehen einfach toll aus, wenn sie veröffentlicht werden. Und ich weiß nicht wie oder warum, aber ich bin glücklich. Ich kann einfach weiterschreiben. Ja.
Henri Seymour:
Ja.
Matt Reiner:
Es wäre toll, jemanden von Easy Agile bei einem dieser Livestreams dabei zu haben. Denn worauf wir uns wirklich konzentrieren, ist einfach eine großartige Möglichkeit, Dinge in Confluence zu erledigen. Wir sind noch nicht in Jira eingestiegen. Ich bin nicht so ein Experte für Jira, aber ich habe darüber nachgedacht, weil dieser Inhalt noch nicht wirklich existiert. Aber es ist nicht unbedingt auf Apps oder K15t auf Apps ausgerichtet. Es ist einfach eine der besten Möglichkeiten, die du gefunden hast, um bestimmte Dinge in Confluence zu tun, und wir teilen sie einfach mit lebenden Menschen, und es macht eine Menge Spaß.
Henri Seymour:
Ja, das klingt toll. Ich habe die Parallele zwischen dem Einstieg in Jira und der Entwicklung von Jira-Apps und Confluence: „Ja, wir haben ein Wiki. Hier schreiben wir Sachen auf.“ Und es ist toll, Dinge wie „Da ist das Bildmaterial auf unserer Dokumentseite“ zu haben. Aber die mache ich nicht. Ich bin damit beschäftigt, Grafiken in einer Jira-App zu erstellen. Ich möchte nicht über diesen Abstand nachdenken. Ich muss meinen eigenen Abstand machen.
Matt Reiner:
Ja. Ja.
Henri Seymour:
Und es ist wirklich so, ich kann einfach schreiben, ich kann einfach das Produkt machen. Ich kann meinen Job besser machen, weil ich mich um diese anderen Dinge gekümmert habe, weil die Experten von K15t das möglich gemacht haben. Und ich hoffe, dass unsere Apps etwas Ähnliches für ihre Nutzer tun können. Das ist das, was wir brauchen, wir müssen nicht darüber nachdenken. Bringen Sie diese App mit und sie wird ein Problem für uns lösen. Sie hilft uns dabei, zu sehen, was wir brauchen, und unsere Informationen in Jira zu organisieren. Was wiederum eine andere Art von Information ist, aber.
Matt Reiner:
Ja, ja. Ja, es ist lustig. Ich habe mit einigen Leuten gesprochen, die den ganzen App-Teil von Confluence in Jira tatsächlich als App Hell beschrieben haben. Das ist ein Begriff, den ich gesehen habe, und ich kann nicht anders, als die Community zu lieben, weil wir uns alle diese Dinge einfallen lassen. Aber die Hölle ist die App, sie entsteht wirklich dadurch, dass man teilweise nicht versteht, was eine Plattform ist. Wenn Sie beispielsweise die Salesforce-Plattform verwenden, ja, das wird zur App-Hölle, wenn Sie wirklich wollen, dass Salesforce eine Marketingplattform ist. Weil Salesforce eine Vertriebsplattform ist. Aber dann gibt es Apps, und Salesforce verkauft sich zufällig sehr. Und dann ist es plötzlich eine Marketingplattform.
Das ist also ein wirklich interessanter Perspektivenwechsel für Leute, die an ein Tool gewöhnt sind, das nur eine Sache tut. Jeder denkt, Excel macht alles. Das tut es nicht, wir sollten es wirklich nur für Tabellenkalkulationen verwenden, Leute. Es ist keine Plattform für andere Dinge. Confluence ist wirklich gut in diesen Kerndingen, Jira ist wirklich gut in diesen Kerndingen. Und dann kommen diese Apps, um die Fragen zu beantworten, für die es keine Antworten gibt, und um die Dinge zu tun, die nicht getan werden können. Und das ist der Grund. Also ist es App Hell oder ist es App Heaven? Das ist die eigentliche Frage. Oder vielleicht ist es vielleicht App Purgatory, ich weiß es nicht. Ich denke, die Zuhörer entscheiden.
Henri Seymour:
Der ständige Strom von, und noch eine weitere App muss aktualisiert werden. Um fair zu sein, denke ich, dass dies derzeit kein Problem in der Cloud ist. Das ist ein ausschließlich vor Ort auftretendes Problem, der ständige Aktualisierungszyklus der Apps. Aber vielleicht nähern wir uns dem Ende des Fegefeuers.
Matt Reiner:
Ja. Ja. Ich glaube, wir steigen alle zusammen auf. Wir erreichen gerade gleichzeitig neue Höhen.
Henri Seymour:
Gibt es noch etwas, das du ansprechen möchtest, während wir über technische Dokumente sprechen?
Matt Reiner:
Ich schätze, ich gehe in die Zeit zurück, als ich an der Universität war. Ich hatte dort einen Manager, der uns in diesem Job auf dem Campus, den ich hatte, sagte: „Unsere Aufgabe ist es, Menschen mit den Ressourcen zu verbinden, die sie bereits umgeben. Du bist kein Lehrer, du bist nur hier, um Menschen miteinander zu verbinden.“ Und das ist mir wirklich im Gedächtnis geblieben. Und das ist im Grunde das, was wir alle tun. Egal, ob wir ein Produkt entwickeln, das Menschen mit Ressourcen verbindet, oder ob das die Ressource ist oder ob wir zur Dokumentation oder zu irgendwelchen Inhalten beitragen.
Wir versuchen wirklich, es den Leuten zu ermöglichen, etwas Größeres zu tun, etwas Höheres, das über unseren Inhalten, über unserem Produkt liegt. Es ist diese Sache, die ihnen wirklich wichtig ist, und jede Rolle, die wir spielen dürfen, und diese größere Sache, diese bessere Sache. Das ist es, worum es geht.
Henri Seymour:
Ja, das ist eine wirklich tolle Perspektive. Das ist wahrscheinlich auch eine wirklich tolle Sache, um das Ende des Podcasts abzurunden.
Matt Reiner:
Ich schätze schon.
Henri Seymour:
Ja. Vielen Dank, dass du zu uns gekommen bist, Matt, und dass du mit uns im Easy Agile Podcast über alles rund um technische Dokumentation gesprochen hast.
PodcastEasy Agile Podcast Ep.34 Henrik Kniberg on Team Productivity, Code Quality, and the Future of Software Engineering
TL;DR
Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.
Introduction
Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?
In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.
This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.
Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.
About Our Guest
Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.
Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.
More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.
Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.
Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.
Transcript
Note: This transcript has been lightly edited for clarity and readability.
Maintaining Team Morale and Motivation in the AI Era
Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.
Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.
Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.
Henrik Kniberg: Thank you very much. It's good to be here.
Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.
What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?
Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."
I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.
"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."
I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.
Creating a Culture of Safe Experimentation
Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?
Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.
Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.
"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."
Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.
The Right Mindset for Working with AI
Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?
Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.
Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.
You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.
"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."
Maintaining Code Quality and Shared Understanding
Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?
Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.
You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?
For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.
But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.
"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."
There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.
It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.
Addressing the Code Review Bottleneck
Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?
Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.
If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.
Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.
"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"
We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.
Ethical Considerations: Balancing Innovation with Responsibility
Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.
Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.
That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.
"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"
It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.
We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.
The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.
I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.
Parallels Between Agile and AI Transformations
Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.
Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.
There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.
Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?
Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.
Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.
"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."
AI for Product Owners: From Ideation to Pull Requests
Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?
Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.
For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.
Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.
"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."
That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.
He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.
Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.
It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.
Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.
Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.
Closing the Gap Between Makers and Users
Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?
Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.
If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.
I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.
"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."
Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.
Looking Ahead: The Future of Agile Teams
Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?
Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.
I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.
But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.
"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."
The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.
As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.
Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.
I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.
I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.
Final Thoughts: Preparing for the Future
Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.
Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.
Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."
Tenille: I'll still keep being nice to my coffee machine.
Henrik: Yeah, that's good. Just in case, you know.
---
Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.
Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.
PodcastEasy Agile Podcast Ep.31 Der Release Train Engineer + SAFe Summit 23
"Lieschen's wealth of experience is absolutely incredible! Not only did she provide invaluable advice, but I thoroughly enjoyed our conversation."
In this episode Caitlin Mackie is joined by Lieschen Gargano Sr, Release Train Engineer at Scaled Agile. They delve into the role of the Release Train Engineer, sharing tips and tricks, FLOW activities, lessons learned and how to get started in the role. With SAFe Summit 2023 just around the corner, Lieschen also takes some time to talk about what she’s most excited about for the event and shared some advice for first time attendees.
If Lieschen's expertise and passion have piqued your interest, be sure to explore the Scaled Agile RTE course. It provides comprehensive training, equipping you with the necessary skills and knowledge to excel as an RTE.
We hope you enjoy the episode!
Transcript:
Caitlin Mackie:
Hi there. Welcome to the Easy Agile Podcast. I'm Caitlin, your host for today's episode. At Easy Agile we specialize in developing apps for Atlassian Jira that help your team move from simply doing agile to truly being agile. Our apps have gained recognition and trust from over 160,000 users across top companies worldwide. With our products, teams can transform their flat Jira backlogs into something visually meaningful and easy to understand. Whether it's sprint planning, retrospectives, or PI planning, our apps are designed to foster seamless team alignment.
Before we begin the episode, we would like to say an acknowledgement of country. This is part of our ongoing commitment towards reconciliation. Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people joining us today. Let's jump into today's episode. So today I'm joined by Lieschen Gargano, a senior release train engineer at Scaled Agile. Lieschen is a highly experienced professional when it comes to change management, system design and stakeholder engagement, and has a passion for developing teams and connecting strategy to execution. Lieschen welcome to the Easy Agile Podcast.
Lieschen Gargano:
Thank you. I'm happy to be here.
Caitlin Mackie:
So Lieschen, you are a release train engineer. For our listeners, can you explain a little bit about the role? For anyone that's not familiar, how would you describe a Release Train Engineer?
Lieschen Gargano:
Yeah. I think one of the easiest ways for people to think of a Release Train Engineer is kind of like a coach or scrum master for the art, for the Agile release train. A servant leader facilitating all of those art events, facilitating the processes and process improvements. And really measured in value delivery, and using flow metrics to measure those improvements and support of the arts.
Caitlin Mackie:
So you mentioned flow metrics there. I've heard a lot about this recently and optimizing flow. What are some of those flow activities that a RT is responsible for?
Lieschen Gargano:
I like to look at feature flow and cycle time. So really looking like are we bringing all of our features in progress at once or are we managing our WIP, not just at the team level but at the art level. Are we taking the whole PI to get a feature through the system, or are we able to finish something before we start the next thing? So I look at that a lot and also just are we making and meeting commitments. Those PI objectives that we set, are we in that 80-100% range? A lot of people want full credit, extra credit and to be in the 120, but for us, predictability really means you tried really hard and you stretched, but you also still made and met commitments. So I look at that really closely too.
Caitlin Mackie:
I love that. You mentioned just then quite a lot of different responsibilities that a RTE has. Do you think that there is one in particular that you really need to get right from the start?
Lieschen Gargano:
Oh, as an RTE, I think the biggest thing is building the relationships and intention. As a servant leader, we really are there to help make the art better, to make being on the art enjoyable and productive and flow. So building that trust and those relationships as a servant leader is the first thing. If you get that wrong, no one will help you do the rest.
Caitlin Mackie:
Yeah-
Lieschen Gargano:
And you need a lot of help. You're not doing anything alone as an RTE.
Caitlin Mackie:
Yes. Yeah, for sure. I can definitely imagine that. Let's go a little bit deeper on that servant leadership that you just mentioned. Can you share your approach and what servant leadership means to you?
Lieschen Gargano:
Servant leadership to me is helping people understand the direction, communicating early and often so that they know where you're going. And then not just saying, "how can I help you get there? What can I do?" But saying, "how can we go together?" A lot of coaching and understanding the problem to solve and connecting it to how it benefits the people. Just like we ask them to connect their work to how it benefits the customer. As the RT, they're my customer. How does what I'm asking you to change benefit you? Not changing is always easier than changing even if we don't like our current state. So why is it worth it?
Caitlin Mackie:
I love that. Yeah, always asking the why and being really clear on it. Yeah, I think that's great. I've done some LinkedIn digging of your profile, as you do, had a little bit of a stalk and noticed that you hosted a webinar recently on tips and tricks and lessons learned as an RTE. Can we start with maybe some tips and tricks? What can you share?
Lieschen Gargano:
The first thing I will say is lean on the Scrum master team, and if you're lucky enough to have an Agile coach or another RTE, lean on that team. Your lean Agile Center of Excellence, those people have the expertise. They're also building the relationships. They're there to help you. Don't try to just prove yourself or go it alone, it's not possible. That team is your team for success. So 100% go to them. They're a wealth of knowledge, a wealth of relationships, and the best support.
Caitlin Mackie:
Yeah, I know it's so important to have that support network around you. You just mentioned the Agile Center of Excellence. Maybe for some of our listeners aren't familiar, could you explain what that is?
Lieschen Gargano:
Yeah, so the Lean Agile Center of Excellence can look a few different ways depending on your organization. At our organization, it is the coach, release managers, RTEs and Scrum masters or team coaches. And some larger organizations than ours might have that hub and spoke model of a centralized change leader. And then RTEs and Scrum masters that are in different arts and around the org. And some even have separate laces in different parts of the organization if it's really big. But really they are that community of practice that holds your lean Agile practices and the standards of those practices and talks to each other and debates and evolves them to make sure that it's consistent throughout the org. That the org is getting consistent coaching, consistent guidance, and they're not being told five different things about how to transform. Because again, change and being lean is so hard. If you add too many voices into that coaching, it gets really overwhelming for folks.
Caitlin Mackie:
Yes, 100%. And an Agile transformation is already overwhelming as it is, so you can imagine that laid on top. I suppose speaking, if we explore a little bit around those on an agile transformation journey, at what point would you say it's important that that lean Agile Center of Excellence is formed?
Lieschen Gargano:
Oh, I think it should be in place pretty quick. I mean, we talk about training your leaders, training your experts and then doing safer teams and launching trains. You need that Center of Excellence there from the start so that they can go out to the rest of the org that they can do all that training and they can be there to support people through title changes, role changes. Launching an art can feel very scary to folks. If you don't have that in place beforehand, you're going to have a lot to reel in after the fact.
Caitlin Mackie:
Yeah, I really like that. It's almost having this really solid foundation and unified voice to sort of go forward and support the rest of the org.
Lieschen Gargano:
And it's so great to have consultants support, to have partners come in and help you and to have the right tools, but they need the help of people inside. They need that lean Agile Center of Excellence of employees inside the company to help you be successful. As an RTE, you need your team. Anybody, any tool, any people trying to do a change, a transformation are going to need that Center of Excellence because all those parts, that's what makes the whole.
Caitlin Mackie:
Yeah, yeah, definitely. So you mentioned as an RTE, a big tip or trick is to rely on that lean Agile Center of Excellence. What do you think has been your biggest lesson learned as an RT?
Lieschen Gargano:
There are a few things that have been particularly difficult for me. One of them is that I don't like to say no and not in that I take on too much or whatever, but more in that if someone has passion for something, I want them to be able to take it on. I want them to be able to move forward with it. And there are times where we really have to say it's too much change. It's too much for this group to manage. In particular, the Scrum Masters and RTEs people come to us for a lot of things and they need that consistency from us, and they need predictability in a change to feel like we know where they're going and if we introduce too many things or if we try to hold too many things at once, it's easy for us to forget about it later or drop something else. So learning when and how to say no, again not necessarily in that capacity way, but just in the width of change, if that makes sense.
Caitlin Mackie:
Yeah, definitely. I think that what you just said there, learning how and when to say no. I think that's not even exclusive to the RTE role as well. I think that's an amazing piece of advice for anyone listening and to share across our audiences, because I know it's definitely something I struggle with as well. So that's my takeaway from this is to, okay, I'm going to constantly imagine like 'no Lieschen told me to when and how to say no', and just focus on that. So yeah, I think that's a great piece of advice. What was your journey like to an RTE? I know we caught up last week and I got a little sneak preview into this, and I know it wasn't straightforward, so if you can share a little bit about that, that would be great.
Lieschen Gargano:
Yeah. I actually started in conflict resolution. I worked in public private reconciliation doing a lot of natural resources facilitation, so hundreds of people, governments, companies, private landowners, residents, trying to bring all those people together to get to consensus or at least to build relationships that allow them to move forward. So really strong foundation and facilitation in particular, and just day-to-day conflict. When we say conflict, we get so worried, 'oh, I don't do conflict', well conflict's everything all the time. It's all the disagreements we need to succeed in life. So that gave me a great foundation when I became a scrum master, and I did that for a few years working with development teams. One of my favorite teams was our infrastructure team, 10 foot pole because no one wanted to touch their work or the 10 foot pole, and I learned so much there and eventually became a coach and started doing more strategic planning and coaching parts of the organization that weren't used to being on arts. Marketing and other groups, which helped me transition to Scaled Agile, where I started working with our CMO and as he grew the marketing team, helping coach that marketing group into an agile way of working, a safe way of working, before actually becoming a product owner, because I loved organizing around value, and I loved those different topics that we were working on internally.
And one of the people I work with at Scale Agile said, "well, help us develop the product then for everybody else". So I did that for a little while, which gave me so much power in that learning how to say no and prioritize and coaching people to decisions is one thing, but as the product owner, I had to practice being where the buck stopped. There are five right decisions, just make one so that people are unblocked, and that prepared me really well for transitioning into RT.
Caitlin Mackie:
Yeah. You have such a wealth of experience there across so many different roles, and you can really see that each of those key roles have taught you something valuable that you can take into this RTE role. So I think that's amazing. It's so cool to see that even though it's not this straightforward linear journey, there's all these parts that there's traits within each that ladder up to helping you succeed as an RT. So I think that's really cool.
Lieschen Gargano:
And I know people are afraid to make some of those lateral moves sometimes, but the skills that you can build might just be that thing that gets you other open doors that you didn't even think about.
Caitlin Mackie:
Yeah. Yeah. I absolutely love that. Yeah, just embrace every opportunity for what it may be, what it may not be. You don't know until you give it a shot. So I think, yeah, I love that. I think that's really great advice. So everything we've spoken about in regards to being a Release Train Engineer may have really hit the spot for some of our listeners. How does someone get there? Were there certifications, courses? What's the process that way?
Lieschen Gargano:
Another thing I probably did backwards. I started with a scrum master cert and then actually ended up getting a SPC certification through Scaled Agile when I was a coach. Because I was a coach before I was an RTE, and I learned about so many other parts of the business that way. But then to become an actual RTE, taking the safe RTE course, but then actually there's a community of RTEs... Which we didn't really talk about this, but being an RTE is a lonely thing. I said earlier, if you're lucky to have another RTE, this is a lonely role. You're really kind of on your own. So not just getting that cert, but being part of that community and being able to send people messages and ask them crazy questions was part of my certification process, but also just community building to where I could feel like I had the connections and competence. So yeah, I found all of them similar to holding each of the roles, also getting that certification, just another tool in the tool belt.
Caitlin Mackie:
Yeah, for sure. I don't want to touch on something you said there about an RTE being sometimes quite a lonely role. What do you think makes it lonely?
Lieschen Gargano:
It's a role that a lot of people have strong opinions about what they need and what success looks like based on where they are in the organization. And there are usually few of you, and even if you're in a large organization with many, you're with your art, you're very focused on your section, and so having all of those pulls and expectations and not having anyone who understands what that feels like just makes it kind of lonely. Now that we have two RTEs and a coach at Scaled Agile, it makes a big difference for me because they are right there in it with me and it's very helpful.
Caitlin Mackie:
Yeah. You can see in that scenario why that community of RTEs is like you said, so important to lean on them as well. Yeah.
Lieschen Gargano:
I find even just connecting to RT's outside our organization too. I grabbed beers with one a couple weeks ago. Those little things, even if you can find that person, meet them at a summit, meet them out in the wild, find them on LinkedIn and just say, "Hey, we live in the same area. We have the same role". It can go a long way because it may seem weird to reach out like that, but they probably are looking for that connection too.
Caitlin Mackie:
Thank you so much for sharing. And for any of our listeners, I might pop some links to any certifications and some scout Agile courses. I'll pop that in our episode notes, so feel free to check those out. You mentioned about connecting with other RTs and meeting at summits, which is a really nice segue to the next part of our conversation. Just around the corner is the 2023 Safe Summit and we're heading to Nashville Music City. What can we expect from Safe Summit? What are you looking forward to?
Lieschen Gargano:
Well, what I'm most looking forward to is that I am putting together an RTE breakfast. So all RTEs are welcome, or even if you're a solution train engineer or you do the role of an RTE with a different title. I'm really excited to meet with those folks over breakfast and just chat it out. And my goal with that really is to have people to connect with so that as we go through the rest of the summit, listening to the talks that we have people enroll, that we can check back in with over drinks and stuff on the later days and say, 'oh, what do you think? How might that work?' So that's what I'm most looking forward to.
Caitlin Mackie:
Amazing.
Lieschen Gargano:
But obviously there are going to be some great talks and the product labs are always really fun. We get to play with the product together.
Caitlin Mackie:
Yeah, cool. Tell me a little bit about the product labs, what's involved in that?
Lieschen Gargano:
The product team puts it together and they have computers set up and you can bring your own and they talk through some of the new releases or things they're working on and help you log into it and use it in your context, but also try to get some feedback on how it works or how you might use it in your organization. So it's a nice two-way street. It's sort of, 'I need this, how might I do it?' And then them saying, 'well, why don't you try and let me see how it works and how we should change it based on how you interact with it'. So it's just really fun. It feels really practical because it's so hands on.
Caitlin Mackie:
Yeah, amazing. I love that. I'm definitely going to have to try and come along and suss that out. It sounds really great. Where do you hope or where do you think we'll see a lot of conversations focused at this year's Safe Summit?
Lieschen Gargano:
At Safe Summit I think the conversations will be really focused on just the day-to-day of Safe. We have new topics that come up. We obviously have new ideas that are going to be presented. But every time I go to one of these, it really is the connecting one-on-one to say, here's where I'm stuck, here's what I'm trying to learn. So we'll hear a lot about Flow, we'll hear about Team Topologies, but we'll also hear those 'I'm just getting started and we're stuck, we have change fatigue. We don't know if our arts are set up correctly'. A lot of those classic conversations that are just really impactful and why people come together.
Caitlin Mackie:
Yeah, definitely. Yeah, I love that. Creating these spaces for people to bond over shared experiences and problems they're facing or wins they're seeing and sharing them. I think that's where these events are amazing for creating that kind of environment. Lieschen, this is my very first Safe Summit. I haven't been to one before and I'm really excited. What advice would you have for first time attendees, returning attendees, what's the way to get the most out of Safe Summit?
Lieschen Gargano:
If you're attending with other people from your organization, the best thing is to split up so you can cover more ground and then come back together and share. The second advice is find people with a similar role as you, because again, you can do that same thing with those folks and split up and then meet up again and try to talk about it in your context. It's great to do that at the parties too, because we throw great parties, but that's the best because no matter what room you end up in, what talk you end up at, you're going to get a great nugget. But where it really sinks in for me is talking with someone else about what I heard and then thinking about, 'okay what does that mean?', when I go home.
Caitlin Mackie:
Amazing, great advice Lieschen. If anyone listening happens to also be attending Safe Summit and they see Lieschen on the floor or myself, make sure you say hello, and if you've got any questions for Lieschen about the podcast episode, I'm sure she'll be more than happy to answer and engage in a great conversation. And anyone looking to get advice around the RTE role, make sure you find her and have a chat. Lieschen I'm really excited to meet in person. We've done this podcast with yourself in the States, myself in Australia, so I'm excited to connect over in your world. And yeah, really thank you so much for your time. I hope you enjoyed the episode. I know, I sure did.
Lieschen Gargano:
I did. Thank you.
Caitlin Mackie:
Thanks, Lieschen.