Easy Agile Podcast Folge 27 Inklusive Führung
„Es war mir eine Freude, mit Ray darüber zu sprechen, Teams zu stärken und Menschen zu helfen, ihr volles Potenzial auszuschöpfen“ - Mat Lawrence
Mat Lawrence, Chief Operating Officer bei Easy Agile, wird von Ray Arell unterstützt. Ray arbeitet derzeit als Direktor für Agile Transformations bei Dell Technologies, ist der Moderator des ACN-Podcasts und Vorsitzender des Verwaltungsrates der gemeinnützigen Forest Grove Foundation Inc.
Ray hat eine Leidenschaft für kollaborative und integrative Führung und liebt es, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Genau darauf tauchen Mat und Ray in dieser Episode ein.
Ray und Mat beschäftigen sich mit Konzepten wie inklusiver und situationsbezogener Führung und dem Zusammenhang mit agilen Arbeitsweisen, der Stärkung des organisatorischen Gehirns und der Förderung der Authentizität innerhalb von Teams.
Dies ist eine fantastische Episode für angehende, aufstrebende und bestehende Führungskräfte! Viele tolle Tipps und Ratschläge, die wir mit Kollegen und Freunden teilen können, um zu verstehen, wie wir uns gegenseitig stärken und befähigen können.
Wir wünschen euch viel Spaß mit der Folge!
Transkript:
Matthew Lawrence:
Hallo Leute, hier ist Mat Lawrence. Ich bin der COO bei Easy Agile und freue mich sehr, heute von Ray Arell begleitet zu werden. Bevor wir zu unserer Podcast-Folge übergehen, möchte Easy Agile den traditionellen Hütern des Landes, von dem aus wir heute senden, danken, den Menschen im Gadigalsprachigen Land. Wir erweisen den Ältesten in der Vergangenheit, Gegenwart und in der Zukunft unseren Respekt und zollen allen Ureinwohnern der Torres Strait Islander und den First Nations, die heute zu uns kommen, denselben Respekt aus. Ray, danke, dass du heute zu uns gekommen bist. Ray ist eine kollaborative und integrative Führungskraft, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Ray verfügt über 30 Jahre Erfahrung im Aufbau und in der Leitung herausragender multinationaler Teams in Fortune-100-Unternehmen, gemeinnützigen Organisationen und Startups. Darüber hinaus ist er als führender Experte für groß angelegte agile Adoptionen, technische Verfahren sowie schlanke und komplexe adaptive Systeme anerkannt. Also Ray, willkommen, wirklich schön, dich heute im Podcast zu haben.
Ray Arell:
Ich danke dir.
Matthew Lawrence:
Ich liebe es, zunächst zu verstehen, was Ihnen an der Arbeit als integrativer Leiter und der Arbeit mit Teams am besten gefällt.
Ray Arell:
Ja, also ich bin wahrscheinlich seit etwa 15 Jahren in Führungspositionen tätig und leite Teams unterschiedlicher Größe. Wenn Sie die intimeren, kleineren Teams von vielleicht fünf oder sechs Personen haben, mehr als Teams, die aus mehreren hundert Personen bestehen, die in einer Organisation arbeiten, deren Leiter ich sein könnte. Und was mir daran am meisten Spaß macht, ist der Kontakt zu den talentierten Leuten, die die Arbeit machen. Ich meine, wenn man in die Führung geht, ist eines der Dinge, von denen man quasi abgeht, nicht die fachkundige Person im Raum zu sein, die programmiert oder Hardwareentwicklung oder etwas anderes macht. Sie haben diese Leute, die jetzt nach einer Richtung oder Vision oder anderen Dingen suchen, um ihnen einen Sinn zu geben, damit sie ihren Tag voranbringen können.
Und ich coache gerne. Ich genieße Mentoring. Ich meine, ein Großteil meiner technischen Seite ist heute mehr Nostalgie, als es bei den neuesten Technologien relevant ist. Es ist bereichernd, wenn man jemanden sieht, der, wenn man an Daniel Pinks Arbeit denkt, die von Autonomie, Meisterschaft und Zielstrebigkeit geprägt ist, plötzlich merkt, dass er sich mit dem Ziel beschäftigt, das wir als Organisation verfolgen, und dann die Autonomie hat, einfach seinen Tag zu verbringen und mit anderen zu arbeiten und zusammenzuarbeiten. Und das war schon immer aufregend für mich.
Matthew Lawrence:
Das kann ich nachvollziehen. Ja. Ich denke, in unserem heutigen Publikum werden wir eine Mischung aus aufstrebenden Führungskräften, aufstrebenden Führungskräften und erfahrenen Führungskräften haben. Ich würde gerne auf Ihre Erfahrung zurückgreifen und idealerweise ein wenig zu einem früheren Zeitpunkt Ihrer Karriere zurückspulen, als Sie in die Führungsrolle übergegangen sind. Und ich würde gerne wissen, was zu dieser Zeit einige der Erfolge waren, die Sie in Ihrem Ansatz gesehen haben und den Sie im Laufe der Jahre zu wiederholen versucht haben?
Ray Arell:
Nun, ich denke, schon früh, glaube ich, besonders wenn man in den technischen Rängen aufwächst und plötzlich zumindest in dem Unternehmen, in dem ich zu der Zeit war, eine sehr fachkundige Kultur, wenn Sie die klügste Person im Raum waren, sind das die Leute, die sie sich angesehen haben und gesagt haben: „Okay, wir werden Sie zum Leiter befördern, oder wir werden Sie zum Manager befördern oder Sie in die Führungspositionen befördern.“ Ich denke, wenn ich darauf zurückblicke, denke ich, Ray 2.0 oder Ray 3.0, egal welche Version ich zu der Zeit hatte, dass ich sehr stark von dieser fachkundigen Führungsposition geleitet wurde, was irgendwie bedeutet, dass ich weiß, was der beste Weg ist, um etwas zu liefern, und jeder sollte meinem technischen Beispiel folgen, wie auch immer dieses Produkt zusammenkommt.
Und ich glaube nicht, dass das wirklich ein guter Ansatz war. Ich denke, das hat die Leute eingeschränkt, weil man den Leuten letztendlich mehr oder weniger einfach gesagt hat, was sie tun sollen, anstatt ihnen zu erlauben, zu experimentieren und zu lernen und sich weiterzuentwickeln, um zu dem zu werden, was ich als leitende technische Person geworden war. Ich denke also, die erste Lektion, die ich gelernt habe, war, dass die Führung eines Teams aus einer Expertenperspektive wahrscheinlich nicht der beste Ansatz ist, wenn Sie gehen... vor allem, wenn Sie an agile und andere integrativere Teamwork-Projekte denken, sollten Sie den Mitarbeitern einen eher katalytischen oder katalytischen Führungsstil geben, der auf Synergien basiert, damit sie sich selbst organisieren und als Ingenieur lernen und wachsen können.
Matthew Lawrence:
Gibt es Zeiten, die für Sie besonders auffallen und in denen Sie es furchtbar falsch verstanden haben? Ich weiß, dass ich ein paar Geschichten habe, die ich auch gerne teilen kann.
Ray Arell:
Ich würde gerne ein paar von deinen hören. Ich finde furchtbar falsch, ich denke, es ist... Die Frage ist, ist etwas jemals wirklich nicht reparierbar, nicht wiederherstellbar? Und in den meisten Fällen waren die meisten Probleme, mit denen wir uns befasst haben, behebbar. Ich denke, wenn ich mir das so ansehe und wieder in diese Haltung zurückkehre, stelle ich ein Team zusammen oder stelle ich nur eine Gruppe von Personen zusammen, die einfach ihre Arbeit vom Manager nehmen und sie wie Karten verteilen... Ich denke, zu Beginn war der große Fehler wahrscheinlich, einfach zu kontrollierend zu sein, und der Fehler dieser Kontrolle bedeutete, dass ich keinen Urlaub haben konnte. Andere waren voneinander abhängig, anstatt voneinander abhängig zu sein. Und ich denke, dadurch lief die Organisation langsamer und nicht so effizient, wie sie sein könnte.
Matthew Lawrence:
Ich habe mir sicherlich schon früher in meiner Führungskarriere denselben Ansatz schuldig gemacht, als ich zum Engpass wurde, absolut.
Ray Arell:
Ja. Genau.
Matthew Lawrence:
Und um das zu erkennen, kann es ziemlich schwierig sein, es rückgängig zu machen, aber es lohnt sich auf jeden Fall, daran festzuhalten. Noch etwas, bei dem ich das Glück hatte, eine Ausbildung in situationsbezogener Führung zu erhalten, oh, wahrscheinlich vor fast 10 Jahren. Und das hat mir wirklich die Augen für einen Ansatz geöffnet, die Art und Weise, wie ich verschiedene Leute in meinem Team behandelte. Aber ich habe sie so behandelt, wie ich sie zuerst beurteilt habe. Wenn ich also [unverständlich 00:07:01] einen Experten und einen Meister sehen würde, würde ich sie als Experten und Meister in allen Dingen behandeln. Und [unverständlich 00:07:05] Wenn jemand zu diesem Zeitpunkt seiner Karriere weniger fähig wäre, würde ich das Gleiche annehmen. Und so würde ich für alles das gleiche Maß an Orientierung oder Orientierungslosigkeit auf diese Leute anwenden. Und bei der situativen Führung ist die Prämisse für diejenigen, die es zu Hause nicht wissen, die Prämisse, die man vorgibt, je nach der jeweiligen Aufgabe, die man vorgibt. Haben Sie diesen oder einen ähnlichen Ansatz verwendet, um festzulegen, wie Sie Menschen auf unterschiedliche Weise einbeziehen?
Ray Arell:
Nun, um Menschen einzubeziehen, gehört es meiner Meinung nach dazu, dass du... Wie du schon sagtest, du hast jede Person situativ betrachtet und sie so strukturiert, dass sie von einer Art, einem Ansatz, von sehr individuellem Umgang mit jemandem geprägt war. Ich denke, die Philosophie, die ich... Nicht jeder ist sehr offen oder kann sehr gut über seine Fähigkeiten und Stärken kommunizieren, oder in bestimmten Fällen sind manche Menschen vielleicht gut in etwas, üben es aber nicht aus, weil sie selbst das Gefühl haben, dass das nicht zu ihren Stärken gehört, aber in Wirklichkeit ist es so. Ich denke also, wenn Sie aus einer situativen Führungsperspektive sagen, wenn Sie jemanden daran zweifeln hören, dass er derjenige sein könnte, der etwas tun oder, sagen wir, sogar die Führung von etwas übernehmen könnte, denke ich, dass ein Teil davon einfach in das gesamte Coaching und Mentoring einfließen und es wirklich einrichten und ihnen dabei helfen, erfolgreich zu sein.
Und aus einer inklusiven Perspektive denke ich, dass es ein gewisses Maß an Ehrlichkeit gibt, das man in seine Arbeit einbringen muss, und Demut, wenn es darum geht, bescheiden zu sein, auch wenn es um das geht, was man erreicht hat. Denn gerade im Ingenieurwesen tendiert man dazu, zu beobachten, dass, wenn man Leute in einen Raum bringt, die Leute, die neu sind, sich zurücklehnen und sich demjenigen hingeben, von dem sie glauben, dass er die mehr Erfahrung hat. Und die Realität ist, dass sie, sagen wir, sagen wir, sie kommen gerade von der Uni. Sie haben vielleicht mehr Fähigkeiten in einem bestimmten Bereich, basierend auf dem, was sie gerade in ihrem Lehrplan durchgemacht haben, als wir vielleicht nicht. Also die Frage, wie wir das gesamte organisatorische Gehirn nutzen, um alle Ideen auf den Tisch zu bringen, erfordert meiner Meinung nach manchmal, dass wir in der Lage sind, effektiv zuzuhören und manchmal einfach innezuhalten und den Leuten zu erlauben, das Wort zu haben und den Stift in die Hand zu nehmen und nicht den Raum zu besetzen, wenn das Sinn macht.
Matthew Lawrence:
Das tut es wirklich, und ich glaube, ich habe das in jedem Unternehmen gesehen, in dem ich bis zu einem gewissen Grad gearbeitet habe. Es würde mich wirklich interessieren, wie Sie mit diesem Szenario umgehen. Für die Leute, die zuhören und mit dieser Situation konfrontiert werden, ist es vielleicht das erste Mal, dass sie eine Führungsrolle übernehmen und dieses Szenario sehen und beobachten. Gibt es einen Rat, den Sie ihnen geben würden, um diese Dynamik zu ändern?
Ray Arell:
Nun, erstens, ich werde mir dessen gerade bewusst. Ich kritzele oft, wenn ich in einer Gruppe von Leuten bin, und ich setze mich hin und mache Punkte auf ein Papier, wo sich die Leute im Raum befinden, und dann fange ich an, Linien zwischen diesen einzelnen Punkten zu zeichnen, wenn ich sehe, dass die Kommunikation zwischen bestimmten Spielern stattfindet. Und was interessant ist, wenn man sich das über einen Zeitraum von etwa 15 Minuten anschaut, beginnt man, dieses Muster zu erkennen, dass vielleicht jemand das Gespräch dominiert oder dass er im Mittelpunkt der Konversation steht und es nicht im ganzen Raum herumgeht. Das ist der Zeitpunkt, an dem du zum Torwächter wirst und andere zur Konversation einlädst. Und dann hilfst du denjenigen, die das Gespräch dominieren, höflich, eine Pause einzulegen, einfach Raum zu geben und den anderen Leuten zu erlauben, zu reden und das herauszuholen.
Und dann denke ich an die Frage, ob das, was die Person sagt, manchmal mit dem Gespräch kohärent ist oder nicht, oder vielleicht versucht sie immer noch, etwas über die Dynamik von allem zu lernen. Man muss nur helfen, manchmal, das aus den Leuten herauszuholen, und offene Worte verwenden, um im Grunde einen Satz zu eröffnen... Ich meine, ein paar offene Fragen, um ihnen das zu beantworten. Und ich denke, das funktioniert wirklich gut.
Matthew Lawrence:
Ich liebe das. Ich kritzele auch. Ich bin Künstler in meiner frühen Karriere, und ich habe mich vor langer Zeit daran gearbeitet, Probleme mithilfe von Technik zu lösen, aber ich kann immer noch nicht... Ich brauche diese physische Zeichnung, um meinen Geist zum Denken zu bewegen, genauso wie alles andere [unhörbar 00:12:30] als nur auf einem Block zu kritzeln.
Ray Arell:
Das Gleiche hier.
Matthew Lawrence:
Etwas, das Sie vorhin gesagt haben, wir haben ein wenig über Inklusivität gesprochen. In Ihrer LinkedIn-Biografie sprechen Sie davon, eine integrative Führungskraft zu sein, die es liebt, andere zu inspirieren und zu motivieren, ihr volles Potenzial auszuschöpfen. Etwas, das mir wirklich am Herzen liegt, ist, dass vor allem der letzte Teil darin besteht, Menschen zu helfen, ihr volles Potenzial auszuschöpfen. Deshalb liebe ich es, ein Personalleiter und COO zu sein. Das können Sie in einem ganzen Unternehmen tun. Ich würde gerne zuerst auf die Idee eingehen, eine integrative Führungskraft zu sein. Wie definierst du, was es bedeutet, eine zu sein?
Ray Arell:
Nun, inklusive Führung, es gab eine alte Tasche, die ich früher hatte, eine kleine Coaching-Tasche, die ich immer mit mir herumtrug. Und ganz oben stand: „Bring es ins Team“, war das Motto, das ganz oben drauf stand. Und ganz unten auf der Tüte stand im Grunde: „Behandle Menschen wie Erwachsene.“ Waren die beiden Kernpunkte, von denen ich glaube, dass Inklusion darin besteht, dass ich akzeptieren muss, dass, ja, ich ein kluger Mensch bin, aber treffen wir eine bessere Entscheidung, wenn wir das im Team besprechen? Sehen wir, welche anderen Ideen oder Möglichkeiten wir uns vorstellen? Im engeren Sinne, treffen Sie die Entscheidung so spät wie möglich.
Es geht eher um die östliche Kultur, also, wenn ich die Entscheidung offen lasse, finden wir vielleicht etwas, das billiger oder besser oder auch einfach aufregender für unsere Kunden ist. Ich denke, ein Teil davon ist zu wissen, dass Sie nicht derjenige sein müssen, der die Entscheidung treffen muss. Sie können das Team die Entscheidung treffen lassen. Und wir alle umarmen uns, weil wir uns damit stärken. Das dachten wir alle, nicht nur das, was Ray dachte, was ich cool finde.
Matthew Lawrence:
Zu dem Artikel, über den Sie in Ihrer Biografie gesprochen haben, gibt es einen zweiten Teil, in dem es darum geht, andere zu motivieren, ihr volles Potenzial auszuschöpfen.
Ray Arell:
Ja, ja.
Matthew Lawrence:
Ja. Lassen Sie uns darüber sprechen, woher das für Sie kam, diese Leidenschaft, und wie Sie aufstrebenden Führungskräften helfen wollen, ihr volles Potenzial auszuschöpfen?
Ray Arell:
Ja, ich meine, ich hatte das Glück, als ich zur Intel Corporation kam, dass Andy Grove die Organisation zu der Zeit noch leitete. Tatsächlich hat er meinen Welcome to Intel-Kurs abgehalten. Zu der Zeit, als ich zu Intel kam, gab es nur etwa 32.000 Mitarbeiter. Und hier ist der CEO, Gründer des Unternehmens, der den Welcome to Intel-Kurs unterrichtet, den ich unglaublich cool fand, eine großartige Erfahrung. Er strahlt diese Führungsstärke aus, egal in welchem Mojo oder was auch immer es ist, er geht in die Umwelt, während er über das Unternehmen spricht. Aber er war wirklich stark im Einzelgespräch, der Zeit, die Sie mit Ihrem Manager oder anderen innerhalb der Organisation verbringen können, weil Sie mit jedem im Unternehmen ein Einzelgespräch führen können. Und das hat er gefördert. Und ich denke, das hilft... Wenn jemand versucht, es herauszufinden, ist er ganz neu im Unternehmen, und du bekommst eine ständige Einladung vom CEO, auf der steht: „Du kannst kommen und ein Gespräch mit mir führen“. Ich denke, das legt die kulturelle Norm von Anfang an fest, dass dies ein Ort ist, der mir bei meiner Karriere helfen und helfen wird.
Und ich könnte Ihnen sagen, dass es verschiedene Zeiten gab, in denen sich daraus ein ausgewachsener Satz entwickelte: „Ich bin der Mentee und sie sind die Mentoren.“ Und in diesen Beziehungen ist es im Laufe der Zeit so, als würdest du sagen: „Nun, das werde ich weiterzahlen.“ Heute habe ich mindestens sechs oder sieben Mentees, die alle möglichen Fragen dazu haben, wie sie sich durch ihre Karriere begleiten sollen oder ob sie einen bestimmten Bereich haben, auf den sie sich konzentrieren wollten. Und es ist an der Zeit, dass sie mir den Kopf zerbrechen. Und in bestimmten Fällen, wenn ich nicht die vollständige Antwort habe, kann ich sie zu anderen Mentoren weiterleiten, die ihnen helfen können, zu wachsen.
Matthew Lawrence:
Ich liebe diesen Ansatz der Weiterleitung, den Sie dort angesprochen haben. Es ist definitiv etwas, das ich in den letzten Jahren selbst versucht habe, und ich wünschte, ich hätte früher mit dem Mentoring angefangen. Ich hatte das Privileg, in meiner Karriere mit einigen großartigen Führungskräften zusammenzuarbeiten, von denen ich viel gelernt habe. Und als ich mit dem Mentoring angefangen habe, wurde mir klar, wie viel ich als Mentor gelernt habe, weil man nachdenken muss. Du denkst wirklich darüber nach, was diese Leute durchmachen, und projizierst dich nicht einfach auf sie. Und es bestätigt die Begründung, warum Sie Dinge selbst tun, warum Sie so denken. Und es zwingt mich, mich selbst herauszufordern.
Und ich denke, wenn es irgendwas gibt... Ich spreche mit einigen der jüngeren Leute bei der Arbeit, die aufstrebende Führungskräfte sind, und sie sind auf ihre Art außergewöhnlich. Sie haben alle sehr unterschiedliche Hintergründe, aber viele von ihnen haben nicht das Gefühl, bereit zu sein, Mentor zu sein. Das sind sie wirklich. Das sind tolle Leute. Und ich frage mich, haben Sie Leute zu Beginn ihrer Karriere gesehen, die versucht haben, es irgendwie früh weiterzugeben, oder haben die Leute das Gefühl, dass sie bis [unhörbar 00:18:22] warten müssen?
Ray Arell:
Ich denke, es kommt darauf an. Erstens, ich denke, das Bildungssystem, zumindest in den Vereinigten Staaten, hat sich ein wenig verändert. Wenn die Leute ihren Bachelor-Abschluss machen, waren sie früher einfach auf sich allein gestellt, sie haben ihr Buchstudium gemacht. Für diese Studie wurde nur sehr wenig Interaktion oder Teamwork entwickelt. Ich meine, als ich meinen Abschluss in Elektrotechnik gemacht habe, war das nur ich alleine. Es mag gelegentlich Laborarbeiten und Laborprojekte geben, aber das war nicht sehr inklusiv, und es gab auch keine Leute, die so früh Führungspositionen übernahmen. Ich sehe mir jetzt meine Tochter an, die gerade an die Universität geht, und alles ist eine Kohortengruppe. Es gibt Kohorten, die sich treffen. Durch das Studium, das sie machen, müssen sie alle in gewisser Hinsicht die Führung für einen Aspekt eines Projekts übernehmen, an dem sie gerade arbeiten. Ich denke, einige der neuen Leute, die in die Belegschaft kommen, haben quasi die Fähigkeiten, um, wenn sie eine Führungsrolle übernehmen müssen, ein kleines Programm oder ein Projekt durchführen müssen, dafür gerüstet zu sein. Zumindest habe ich das gesehen.
Matthew Lawrence:
Ich liebe dieses Konzept. Etwas, das ich beobachtet habe und darüber spreche ich auch viel mit unserem Führungsteam und unseren Mentor-Führungsteams für die [unhörbar 00:19:56]. Ein Großteil der Gespräche dreht sich um Teamdynamik, Teamvertrauen, Agilität innerhalb von Teams und darum, generell zu versuchen, Teams zu stärken, sie so aufzustellen, dass sie autonom sein können. Sie sind wirklich befähigt und man vertraut darauf, dass sie großartige Entscheidungen treffen und die Arbeit vorantreiben. Sie haben viel Erfahrung mit agilen und agilen [unhörbaren 00:20:21] agilen Führungskräften. Aufgrund Ihrer Erfahrung mit der Leitung agiler Teams, diesen Adoptionen und diesen Transformationen würde ich gerne verstehen, ob Sie einen Zusammenhang zwischen Agilität als Team und den Eigenschaften sehen, die eine integrative Führungskraft haben wird. Gibt es in Ihrem Kopf einen Zusammenhang zwischen dem, was es bedeutet, agil zu sein, und einer inklusiven Führungskraft?
Ray Arell:
Ich glaube schon. Denn wenn Sie schon früh daran denken, haben sie festgestellt, dass Servant Leadership ein besserer Führungsstil für agile Teams ist. Ich denke also, wenn wir über Transformation sprechen, sind einige der größten Fehler, die auftreten, eher darauf zurückzuführen, dass sie nicht agil sind, sondern auf Vertrauensfragen und anderen organisatorischen Hindernissen, die es dort bereits gab, bevor sie gestartet wurden. Und wenn sie diese nicht angehen, ist ihre agile Reise schmerzhaft.
Ich habe Leute sagen hören, dass sie schon einmal Scrummed bekommen haben und es auf eine wirklich abwertende Art nutzen und denken, dass, nun ja, anstatt ein Team von befähigten Leuten dazu zu bringen, innerhalb des Scrum-Frameworks zu arbeiten, sie am Ende unter die Linse des Mikromanagements gestellt werden, weil sich die Kultur des Managers nicht geändert hat und der Manager sie täglich nutzt, um sicherzustellen, dass alle zu 120% arbeiten, im Vergleich zu dem, was wir sehen sollten Das Muster ist, dass das Team seinen Flow versteht. Sie bringen Arbeit in das Team. Es wird nicht geschoben. Und ich denke, diese Dynamik ist etwas, dass, wenn sich die Führung nicht verändert und die Art und Weise, wie sie arbeitet, ändert, sie in Organisationen einfach nicht funktioniert.
Matthew Lawrence:
An den vielen Orten, an denen Sie gearbeitet, Menschen gecoacht und angeleitet haben, stoßen Sie langsam auf... Es gibt einen Begriff, den wir inzwischen für agile Muttersprachler verwenden. Dabei handelt es sich um Menschen, die es wirklich nicht anders gekannt haben, weil so viele Unternehmen auf der Welt agile Transformationen durchlaufen, und das wird noch lange so bleiben. Aber da manche Unternehmen mit Agilität an vorderster Front geboren wurden, haben Sie schon erlebt, dass viele Menschen in Führungspositionen aufsteigen, die nichts anderes wissen als echte Agilität und wirklich authentische Agilität, wie Sie es gerade beschrieben haben?
Ray Arell:
Nun, ich finde es irgendwie interessant, denn als du über diesen Satz gesprochen hast, habe ich darüber nachgedacht, naja, wenn du nichts anderes wüsstest... Aber ich kann auch sagen, dass du einheimisch werden könntest, wenn du auch eine Zeit lang in der Kultur warst. Also kannst du irgendwann... Das wird deine erste Reaktion, deine erste Angewohnheit ist es, mehr aus den agilen Prinzipien herauszuholen, als du aus etwas anderem ziehen würdest. Ja, es gibt diese Leute, aber es war interessant, Unternehmen wie Spotify oder Salesforce oder Pivotal zu beobachten, und ich kann einfach die Liste der Unternehmen durchgehen, die als agile Organisation angefangen haben, sie wurden groß, und dann tauchen plötzlich die Antimuster eines großen Unternehmens in diesen Unternehmen auf. Obwohl also die Leute innerhalb des kleineren Stammes agil arbeiten, fängt das Unternehmen langsam nicht mehr an, agil zu arbeiten. Es fällt in einen größeren Kontext dessen, was wir bei den älteren Unternehmen beobachten.
Und ich denke, ein Teil davon könnte an der Unternehmenskultur liegen, dass sie jemanden von außerhalb mitbringen, der kein Muttersprachler ist, und es fällt ihnen schwer, mit der Vorstellung umzugehen, dass wir irgendwann hier drüben einen Liefertermin festlegen und wir glauben, dass wir ihn einhalten werden. Aber nein, wir haben keinen Plan, den man liebevoll zu 90% mit Zuversicht bezeichnen würde, der besagt, dass wir alle Risiken aus dem Weg geräumt haben. Und ja, es wird auf jeden Fall an diesem Tag passieren. Und einige dieser Unternehmen werden wirklich... Sie haben das Gefühl, dass sie alles auf die Straße legen müssen, und wenn sie es nicht einhalten, haben sie das schon in ein Bonusprogramm für Führungskräfte gesteckt, was leider zu schlechtem Benehmen führt
Matthew Lawrence:
Ja, ich war dort. Ich gehe davon aus, dass wir in unserem Publikum Leute haben werden, die in höhere Führungspositionen wechseln. Sie sind keine aufstrebenden Führungskräfte, sie machen das schon eine Weile, und sie haben wahrscheinlich einige erfolgreiche agile Teams auf der kleineren Ebene geleitet, wie Sie es beschrieben haben. Gibt es für die Leute, die in höhere Rollen, vielleicht in Führungspositionen, aufsteigen, eine Anleitung, die Sie ihnen geben würden, wie sie diese Veränderungen bewältigen und versuchen, sie mithilfe agiler Prinzipien und der Bedeutung von Agilität in diesen höheren Rollen aufrechtzuerhalten?
Ray Arell:
Ja, ich denke, ein Teil davon ist die Arbeit, die Sie als kleineres Team geleistet haben, alles kann immer noch skaliert werden. Und ich hasse es, das Wort Skala zu benutzen, weil ich denke, Maßstab ist irgendwie... Die Leute benutzen es irgendwie... Was wäre das richtige Wort? Es wird in unserer Branche missbraucht. Ich denke, Werte und Prinzipien sind skalenfrei. Sie können immer noch jeden Tag in Ihr Team gehen und sich immer noch an diese 12 Prinzipien halten, und Sie werden gute Arbeit leisten. Die Frage ist jedoch, wenn Sie das auf der unteren Ebene tun, sagen wir mit einem Kanban-Board, ist die Frage, wie es aussieht, wenn Sie an Ihrem Chefschreibtisch sitzen? Was ist die Methode, bei der Sie Poolbillard spielen? Wenn Sie sich die meisten skalierten Frameworks ansehen, die heute auf dem Markt sind, gibt es nur sehr wenige Hinweise darauf, was im Alltag einer agilen Führungskraft sein sollte. Wie sollte das aussehen?
Und wenn ich an das Geschäftsteam denke, arbeitet das Managementteam täglich mit den Lieferteams zusammen. Das sollten sie tun. Also, was werden Sie tun, damit das möglich wird und stattfindet? Was werden Sie tun, um... diese großen jährlichen Budgetprozesse einzustellen? Machen Sie sich Dinge wie die Budgetierung oder andere Dinge zu eigen, bei denen Sie die Organisation strategisch finanzieren und nicht versuchen, alles auf einen jährlichen Rhythmus festzulegen, aber Ihre untergeordnete Organisation arbeitet trotzdem alle zwei Wochen. Sie sollten also in der Lage sein, Ihre Wetten bei jeder Organisation auf der Grundlage der Leistung jedes Sprints erneut zu verschieben. Kannst du das machen?
Das letzte ist wahrscheinlich das wichtigste, sind Hindernisse. Und so schnell braucht es Informationen, um vom untersten Teil der Organisation zum höchsten Punkt der Organisation zu gelangen? Und wenn das bei bestimmten Organisationen drei Wochen, zwei Wochen oder manchmal sogar später dauert, optimieren Sie das. Wie optimiert man ein Hindernis, bei dessen Beseitigung Sie persönlich helfen können, für die Mitarbeiter, damit sie nicht länger gebremst werden, was auch immer das sein mag?
Matthew Lawrence:
Du berührst da etwas, was meiner Meinung nach ein grundlegender Bestandteil von Agilität ist, nämlich diese Fähigkeit zu lernen und sich anzupassen, und du kannst nur lernen, wenn du dir bewusst bist, was um dich herum passiert, du kannst es beobachten [unhörbar 00:28:39].
Ray Arell:
Nun, ich habe vor ein paar Monaten etwas gesagt und alle sagten einfach: „Warum hast du gesagt... Ich kann nicht glauben, dass du das laut gesagt hast.“ Manchmal ist es das leise Zeug, das laut ausgesprochen wird. [unhörbar 00:28:53]. Wir haben versucht, ein Treffen zu vereinbaren, um eines dieser Hindernisse zu beheben, und alle hochrangigen Führungskräfte waren beschäftigt. Sie waren beschäftigt. Und meine Frage war, wenn das momentan nicht das Wichtigste für uns ist, was machst du dann? Wirklich, tust du das in deinem Alltag, wenn das nicht die höchste Priorität ist, die du eingehst? Und die Befragung hochrangiger Führungskräfte, dass sie vielleicht nicht auf die richtigen Dinge achten, und manchmal den Machthabern diese Wahrheit zu sagen, ist etwas, das wir ab und zu tun müssen.
Matthew Lawrence:
Ich stimme zu. Dieses Maß an Offenheit ist definitiv auf allen Ebenen erforderlich und die Fähigkeit, dieses Feedback zu erhalten, damit Sie als Einzelperson lernen und sich anpassen können, wie wir bereits zuvor besprochen haben, darüber, wie Sie als Führungskraft, aber auch als Team anpassungsfähig sind. Es gibt einen Punkt, auf den ich noch eingehen möchte, bevor wir zum Abschluss kommen, nämlich wenn man die Karriereleiter hochklettert und in eine höhere Position kommt und dann für ein breiteres Spektrum von Dingen verantwortlich ist, vor allem, wenn man die Führungsebene erreicht, habe ich erlebt, wie Menschen mit dem Übergang von der Person, von der Sie gleich zu Beginn dieser Diskussion gesprochen haben, zu der Person, die alles weiß und die Regie führen kann und alle Antworten hat in jemanden, bei dem ich sehe, dass sich Ihr Job zu der Person entwickelt, die identifizieren kann, was wir wissen am wenigsten darüber, was wir als Führungsteam am wenigsten wissen, wo wir sind... haben am wenigsten Selbstvertrauen, wo wir die Hindernisse sehen und nicht wissen, was wir mit ihnen anfangen sollen.
Wie gehst du vor, um die Leute dazu zu bringen, das anzunehmen? Weil ich denke, was ich sehe, ist die Angst, die damit einhergeht, fast eine Angst davor, zu sagen: „Oh, ich gebe es Leuten gegenüber zu, dass ich nicht weiß, was ich tue.“ Und ich wurde während meiner gesamten Karriere dafür belohnt, dass ich immer mehr zum Experten wurde, und plötzlich ist es meine Aufgabe, die Person zu sein, die selbstbewusst genug ist, um auszurufen: Das ist es, was wir noch nicht verstehen. Lassen Sie uns zusammenkommen und versuchen, das Problem zu lösen. Wenn das Risiko größer ist, die Auswirkungen größer sind und Sie für mehr Dinge verantwortlich sind, wie helfen Sie Menschen beim Übergang in diese übergeordnete Rolle?
Ray Arell:
Nun, ich denke, ein Teil davon ist, dass sie diese technische Seite loslassen können, wenn sie sich ständig die Hände schmutzig machen müssen? Und ich habe bestimmte Führungskräfte gesehen, bei denen wirklich jemand zurückgehen und sagen muss: „Bist du dir wirklich sicher, dass das die Karriere ist, die du anstreben willst? Sie scheinen mehr darauf aus zu sein, sich mit den Einzelheiten befassen zu wollen, und vielleicht ist das der beste Ort für Sie, weil Sie sich in diesem Bereich wohler fühlen.“ Der andere Aspekt ist jedoch, glaube ich, wieder, dass Vertrauen entscheidend wird, wenn sie sich verändern. Vertraue den Leuten, die für dich arbeiten, dass sie nicht reinkommen und faul sind und du ihnen die ganze Zeit über die Schulter schauen musst, weil du das Gefühl hast, dass sie vielleicht nicht produktiv sind oder andere Dinge. Sie müssen sagen können, dass die Leute, die Sie eingestellt haben, talentiert sind und dass sie uns unseren Zielen näher bringen.
Ich denke, was für die Gesundheit des Unternehmens immer wichtiger wird, ist, dass man viel besser darin sein muss, tatsächlich zu sagen: „Okay, nun, hier ist unsere Vision“, sei es eine Produktvision, ob es die Vision des Unternehmens ist, was auch immer das sein mag, den Menschen zu helfen, zu verstehen, was dieser North Star ist, und das dann nicht aus Ihrer Sicht, sondern aus der Sicht des Kunden zu bekräftigen. Und ich denke, hier fangen viele Unternehmen an zu driften, weil sie anfangen, einige interne Kennzahlen zu optimieren, die, ja, die Effizienz in Ihrem Unternehmen steigern werden. Aber was denkt der Kunde? Und ständig in der Lage zu sein, sich, aus einer agilen Perspektive, als der Chief Product Owner des Unternehmens darzustellen, um das repräsentieren zu können, was die Kunden brauchen und wollen, und in der Lage zu sein, dies in der Vision und den ehrgeizigen Missionen, die für das Unternehmen aufgestellt werden, zum Ausdruck zu bringen. Machen Sie es für die Menschen real.
Und dann ist der letzte Teil davon, dass nicht alles passieren und wahr werden wird. Wenn Sie die Biografien der meisten Führungskräfte lesen, gibt es viele, viele, viele Fehler. Und ich erinnere mich an das von einem Anführer, er ging in den Ruhestand. Und ich dachte, es war nicht gerade peinlich, dass er das tatsächlich getan hat. Er ging tatsächlich auf die Bühne und sprach über seinen größten Misserfolg. Während meiner gesamten Karriere bei der Arbeit mit dieser Person habe ich mich immer gefragt, ob sie ein Mensch ist oder nicht. Und dann, am Tag des Ausscheidens dieser Person, beschlossen sie schließlich, Ihnen ein paar Geschichten über Fehler zu erzählen, die sie gemacht hat. Und ich denke, er musste diese Geschichten wirklich viel, viel früher teilen, weil ich denke, die Leute hätten wahrscheinlich herausgefunden... Sie wären etwas gestresst gewesen, um ihn herum zu arbeiten. Und es würde auch eine gewisse Verwundbarkeit für Sie als Führungskraft bedeuten, zu sagen, dass Sie nicht alles herausgefunden haben, und manchmal ist es nur eine Vermutung. Wir sind der Meinung, dass das Produkt genau dort eingesetzt werden muss.
Und sobald du es den Kunden vorstellst, werden sie dir sagen, ob... Wenn du das Cano-Modell nimmst und plötzlich triffst, das ist die aufregendste Sache seit dem Rad, werden sie es lieben oder werden sie gehen, [unhörbar 00:35:12]. Ich nehme es, wenn es kostenlos ist. Du gerätst in eine Situation, in der es ist, naja, wir können nicht so viel verlangen. Aber ich denke, diese Geschichten werden wichtig und verankern Organisationen. Ein weiterer Aspekt ist meiner Meinung nach, dass, wenn man jemanden hat, der ansprechbar ist und diese Geschichten effektiv in die Organisation weiterleiten und über diese Dinge sprechen kann, das meiner Meinung nach allen anderen die Tür öffnet, dies auch zu tun. Denn ob es Ihnen gefällt oder nicht, Menschen sind hierarchisch in der Art und Weise, wie wir über Dinge denken. Viele Leute schaffen es, also ahmen sie Führungskräfte nach. Seien Sie also der Anführer, den jemand nachahmen möchte.
Matthew Lawrence:
Ich finde, das ist ein toller Rat, Ray. Die Verbindung, die sich für mich durch dieses ganze Gespräch zieht, ist, sich authentisch mit Ihrer Arbeit auseinanderzusetzen, ob es das Team ist, das Sie zu leiten versuchen, ob es die agilen Praktiken sind, egal auf welcher Ebene und auf welcher Ebene Sie arbeiten. Und um dieses Vertrauen aufzubauen, damit das funktioniert, ist ein gewisses Maß an Authentizität erforderlich.
Ray Arell:
Ja, genau.
Matthew Lawrence:
Ich würde mich freuen, wenn Sie zum Abschluss noch letzte Tipps oder Ratschläge für aktuelle und aufstrebende Führungskräfte zu diesem Thema hinterlassen würden. Wenn es einen Weg gibt, der über das bloße Teilen Ihrer eigenen persönlichen Geschichten hinausgeht, wie würden Sie Menschen beraten? Was würdest du ihnen geben, um Vertrauen in ihre Teams aufzubauen?
Ray Arell:
Nun, ein paar Dinge. Erstens, du musst darauf achten, wer du als Person bist. Nochmals, wie ich schon sagte, dass die Leute es schaffen. Und wenn Sie um drei Uhr morgens eine E-Mail verschicken und fünf Minuten später Ihre Mitarbeiter Ihnen geantwortet haben, dann sind Sie kein wirklich gutes Vorbild für eine gute Work-Life-Balance. Viele Ihrer Tendenzen werden sich also auf das Unternehmen auswirken. Machen Sie also unabhängig davon, wie Sie sich selbst einschätzen, eine Bewertung Ihrer Führung, wo sie Ihrer Meinung nach stattfindet. Harvard Business Review hat vor langer Zeit das Niveau dessen, was sie als Führungsmodelle betrachteten, nach hinten verschoben. Und auf der untersten Ebene befinden sich Führungskräfte, die auf Experten und Leistungsträgern basieren. Und wenn Sie zu diesen gehören, sind diese für eine gute agile oder kollaborative Kultur nicht sehr förderlich. Wenn Sie sich also gerade in diese Richtung bewegen, sollten Sie nach Wegen suchen, wie Sie sich eher zu einer Führungskraft entwickeln können, die auf Katalysatoren oder Synergien basiert.
Und diese Reise ist nicht einfach, weil ich sie selbst durchgemacht habe. Es hat Jahre gedauert, bis Sie sich von einigen dieser Tendenzen, die Sie als fachkundige Führungskraft hatten, gelöst haben. Und ein Beispiel: Eine Führungskraft, die von Experten geleitet wird, neigt dazu, nur mit anderen Experten zu sprechen. Wenn sie jemanden als keinen Experten für etwas wahrnehmen, neigen sie dazu, diese Personen zu ignorieren und nicht mit ihnen in Kontakt zu treten. Und wieder ist es das gesamte organisatorische Gehirn, das das Problem lösen wird. Wie binden Sie also die gesamte Organisation ein und bringen diese Ideen zusammen?
Die andere ist, dass Sie, wenn Sie darauf eingehen, aus der Perspektive einer aufstrebenden Führungskraft, es vorhin selbst gesagt haben, und das ist nicht nur die Voreingenommenheit, weil Sie kein Experte sind, ich werde nicht mit Ihnen sprechen, sondern jede Voreingenommenheit, die Sie möglicherweise haben, kann die Art und Weise beeinflussen, wie Sie eine Person führen und beurteilen, und könnte ihre Karriere wirklich einschränken oder ausbauen, vielleicht aufgrund eines schnellen Urteils, das Sie vielleicht gehabt haben. Ich denke, Sie müssen sich Ihrer Entscheidungen bewusst sein, die Sie innerhalb der Organisation treffen, und insbesondere der Entscheidungen, die Sie über Menschen treffen. Und mit denen musst du vorsichtig sein.
Der letzte ist wahrscheinlich nur... Und das geht in den Bereich der komplexen adaptiven Systeme. Nicht alles ist zugeschnitten und trocken, schwarz und weiß oder mechanisch, was bedeutet, dass wir dasselbe Produkt nehmen und es immer wieder und wieder wiederholen können, und wir werden unterschiedliche Antworten bekommen. Wir werden unterschiedliche Anforderungen haben. Wir werden verschiedene Dinge bekommen. Es ist okay, dass das Zeug da ist. Und es ist okay, dass die Dinge, die aus unseren Produkten kommen, ab und zu anders sind, und vor allem, weil alles eine sehr komplexe Umgebung ist. Ursache-Wirkungs-Beziehungen und Komplexität sind, dass der Kunde seine Meinung ändern kann, und wir müssen uns damit wohlfühlen, wenn ein Kunde seine Meinung ändert. Unser Kunde hat möglicherweise neue Bedürfnisse, die auftauchen.
Und auch unsere Mitarbeiter ändern manchmal ihre Meinung oder ändern das, worauf sie sich freuen. Wie fördern Sie das? Wie fördert man diese Mitarbeiter, um sie im Unternehmen zu halten, nicht um sie für die Fähigkeiten einzusetzen, über die sie gerade verfügen, sondern wie geht man da langfristig vor? Und ich weiß, dass ich hier etwas langatmig werde, aber das, was ich am meisten sehe, trotz all der Entlassungsbescheide, die gerade vor sich gehen, ist, dass dieses Unternehmen nicht auf lange Sicht spielt. Ich denke, das ist ein schlechter Schachzug, denn alles, was Sie tun, indem Sie einen Mitarbeiter entlassen, ist, Ihrem Konkurrenten eine ganze Reihe von Wissen zu vermitteln, das Sie behalten sollten. Also wie dem auch sei, ich werde es da kurz machen.
Matthew Lawrence:
Richtig. Danke, dass du heute deine Weisheit mit uns geteilt hast. Es war mir ein absolutes Vergnügen. Ich habe den Chat wirklich genossen. Also ja, danke, dass Sie sich mir im Easy Agile Podcast angeschlossen haben.
Ray Arell:
Fantastisch. Danke, dass du mich eingeladen hast.
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.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.
PodcastEasy Agile Podcast Ep.11 Dave Elkan & Nick Muldoon über den Aufbau von Easy Agile
Folgen Sie in dieser Folge von The Easy Agile Podcast Nick Muldoon und Dave Elkan, den Co-CEOs und Mitbegründern von Easy Agile. Da sie sich auf die nächste Wachstumsphase des Unternehmens freuen, wollten sie diese Gelegenheit nutzen, um über ihren bisherigen Werdegang nachzudenken.
Nick und Dave sprechen über das Wachstum eines Start-ups in der Region Australien, die Suche nach den richtigen Leuten, die Aufrechterhaltung einer positiven Teamkultur und die Bedeutung werteorientierter Teams.„Unser Ziel ist es, Teams dabei zu helfen, agil zu sein, und dabei tun wir das für uns selbst. Wir versuchen ständig, zu lernen, uns anzupassen und mit neuen Dingen zu experimentieren. Ich hoffe, das war ein nützlicher kleiner Leckerbissen und eine Reise von Dave und mir darüber, wie wir Easy Agile zu diesem Punkt gebracht haben.“
- Nick Muldoon, Co-CEO von Easy Agile
„Es gibt diese lustigen kleinen Hacks und Analogien und ich denke, das ist eine Sache mit langfristiger Vision. Wenn Sie ein Unternehmen führen, das diese langfristige Vision und dieses Ziel nicht verfolgt, dann können Sie tatsächlich in mehrere Richtungen gleichzeitig gehen, und Sie werden keine Fortschritte machen.“
- Dave Elkan, Co-CEO von Easy Agile
Abonniere unbedingt, genieße die Folge 🎧
Transkript
Nick Muldoon:
Guten Tag, Leute. Nick Muldoon mit Dave Elkan, Mitbegründer und Co-CEO von Easy Agile. Bevor wir beginnen, möchten wir den traditionellen Hütern des Landes, auf dem wir heute senden und aufnehmen, unsere Anerkennung aussprechen, dem Volk der Wodiwodi der Dharawal Nation. Wir erweisen den Ältesten in Vergangenheit und Gegenwart unseren Respekt und erweisen allen unseren Ureinwohnern, die heute zuhören, den gleichen Respekt.
Nick Muldoon:
Dave, nur ein kleiner Rückblick auf fünfeinhalb Geschäftsjahre?
Dave Elkan:
Geschäft? Ja, eine Achterbahn. Es hat großen Spaß gemacht.
Nick Muldoon:
Es ist eine Achterbahn, nicht wahr? Ich schätze, wo fängt man am besten an? Der beste Ort, um anzufangen, ist am Anfang.
Dave Elkan:
Ja, ich meine, wir können vor dem Start gehen. Es gibt immer ein gutes Prequel. Ich schätze, wir können später eine Prequel-Episode machen. Aber ich glaube, ich erinnere mich frühestens an die Zusammenarbeit mit dir, Nick, war auf Level 15 in der Kent Street, bei Atlassian. Da war dieser rothaarige Typ am einen Ende des Gebäudes, der an Atlassian GreenHopper arbeitete, und ich war zu der Zeit damit beschäftigt, im Kick-Ass-Team zu arbeiten und 2011 den neuen Issue Navigator zu entwickeln, der jetzt der alte Issue Navigator ist. Und dann hast du dich nach San Francisco verschissen und ich bin ihm schließlich gefolgt, und dann haben wir eine Weile da rumgehangen, nicht wahr?
Nick Muldoon:
Ja, ich erinnere mich daran, weil wir uns hingesetzt haben, ich war zurück, um zu heiraten, und wir haben uns hingesetzt und einen Kaffee getrunken und darüber geredet, dass du und Rin nach San Francisco gezogen sind und wie es für Liz und mich gewesen war und wie der Prozess war und all diese Dinge.
Dave Elkan:
Das ist eine großartige Gelegenheit, auch unser Leben auf dieser großartigen Reise zu würdigen, und wenn sie nicht gewesen wären, wären wir wahrscheinlich gar nicht nach San Francisco gegangen, weil ein großer Teil der Werbung darin besteht, ins Ausland zu gehen und das sowieso für mich und für Sie selbst zu tun, da bin ich mir ziemlich sicher.
Nick Muldoon:
Ja. Ja, Liz war dieses große Gespräch darüber, nach Übersee zu gehen und etwas Neues zu erleben. Ich fühlte mich in Sydney ziemlich wohl und genoss meine Rolle im Produktmanagement bei Atlassian, aber es war wirklich ein Anstoß, etwas anderes zu erleben und zu machen.
Dave Elkan:
Absolut, hier genauso. Und du warst über vier Jahre dort, in San Francisco, und ich war drei Jahre dort. Aber du bist nach Hause gekommen, du hast geheiratet und ich habe dich gerade auf einen Kaffee geholt und wir saßen da im Martin Place und unterhielten uns und du sagtest: „Ja, es ist großartig. Komm vorbei, du kannst zwei Wochen bei mir bleiben.“ Und ich sage: „Oh, ich kenne dich kaum.“
Nick Muldoon:Ja, aber es war so viel. Ja, auch wenn ich Liz oder mich nicht kannte, war es viel besser als die Alternative. Also für die Leute, die zuhörten, befand sich das Atlassian-Apartment zu der Zeit in einem ziemlich rauen Teil von The Tenderloin in San Francisco, und es war wahrscheinlich nicht die beste Einführung, wenn jemand nach San Francisco ziehen würde.
Dave Elkan:
Nein. Aber um es kurz zu machen, es gibt eine Menge guter Geschichten, ich bin mir sicher, dass wir sie eines Tages erzählen können, aber irgendwann hatten wir beide Töchter in San Francisco und wir wollten zu Hause und näher bei der Familie sein. Dann kamen wir nach Sydney und stellten fest, dass der Verkehr 20% oder 50% schlimmer ist als zu dem Zeitpunkt, als wir losfuhren und wir entwurzelt wurden. Also, wenn man einmal entwurzelt ist, muss man sich irgendwo wieder hinsetzen und es ist ziemlich einfach, an diesem Punkt umzusteigen, und man hat sich dafür entschieden, Sydney zu verlassen.
Nick Muldoon:
Ja, dieser regionale Lebensstil in Wollongong.
Dave Elkan:
Ja, wo Sie einen ganzen Block Land für sich haben können, ohne das Budget zu sprengen, und Sie können, relativ gesehen, als hätten sich die Zeiten in diesem Bereich ein bisschen geändert, aber seitdem haben wir das verfolgt, nicht wahr? Und wir haben uns Newcastle angesehen und...
Nick Muldoon:
Wir haben uns Newcastle angesehen, Brisbane und Adelaide angeschaut, wir sind sogar durch Wagga Wagga gegangen. Wir hatten das tollste indische Essen in Wagga Wagga, wir dachten fast: „Das ist der richtige Ort. Wenn wir in Wagga so etwas essen können, sind wir süß.“ Etwas zu kalt, aber am Ende haben wir uns für Wollongong entschieden, was zum großen Teil auf die Nähe zum Strand und zum Early Start Discovery Space für die Kinder zurückzuführen ist und einfach ein ziemlich cooler, chilliger Ort, um eine Familie zu gründen. Ich glaube, es gibt auch Aspekte, die Liz und mich wirklich an San Francisco erinnert haben. Wir gingen an einem Samstagmorgen oft auf den Bauernmarkt unten am Ferry Building, und wir fanden den Bauernmarkt an einem Freitag in Wollongong an der Crown Street North, also gab es diese Ähnlichkeiten, die es uns irgendwie ermöglichten, ziemlich einfach von einer Stadt in die andere zu wechseln.
Dave Elkan:
Ja. Es ist ein ziemlich einfacher Ort zum Leben und Verweilen. So wie ich es gerne drehe, ist es gerade weit genug von Sydney entfernt.
Nick Muldoon:
Ja, dazwischen ein netter kleiner Nationalpark.
Dave Elkan:
Stimmt, es kann nicht wirklich auf uns einwirken, es ist nicht erlaubt. Da kannst du nicht bauen, also hast du immer diesen Puffer. Aber ich erinnere mich, dass ich zum Geburtstag einer Nichte nach Sydney zurückkehrte und mir 9$ pro Stunde für das Parken am Strand berechnet wurden, wenn man bedenkt, dass du nicht einmal mehr eine Parkplakette hast, weil ich kein Anwohner war, und ich dachte: „Wow, das ist wirklich teuer.“ Aber für alle, die nach Wollongong oder in die andere Richtung kommen, können Sie kostenlos am Strand parken. Das ist quasi ein guter Lackmustest für den Unterschied, über den wir hier sprechen.
Nick Muldoon:
Mm-hmm (bejahend). Ja, ich schätze, dieses regionale Leben, als ob wir hier nicht wirklich eine Technologiebranche hätten. Wir kommen aus Sydney, wo es vor 10 Jahren diese aufstrebende Tech-Szene und SyDJs, SydCSS und andere Meetups gab, und in San Francisco wurden wir mittendrin gedrängt. Ich erinnere mich, wir haben letzte Woche über ein Treffen gechattet, bei dem wir uns getroffen haben, den Ruby Creator bei einem Heroku-Treffen, glaube ich, und eine Sitzung über [detrace 00:06:17] in der Firma, die jetzt pleite ist und an deren Namen ich mich nicht einmal erinnern kann, aber wir waren mittendrin bei all den Meetups in San Francisco. Dann gab es in Wollongong nichts davon, und so war es wie eine Frage, was wir tun könnten, um auch hier eine Gemeinschaft aufzubauen, zu versuchen, andere Gleichgesinnte zu treffen?
Dave Elkan:
Ja, es war definitiv dieser Wunsch, nicht wahr? Und wir haben uns vorgenommen, das zu tun, und ich glaube, es war Rin, der es Siligong genannt hat. Ich erinnere mich, dass wir vor unserer Abreise tatsächlich über das Siligong-Tal gesprochen haben, und wir haben einfach beschlossen, das zum Namen der Gemeinde zu machen. Ich habe neulich auf meine alten E-Mails zurückgeschaut und dachte: „Oh, wir haben tatsächlich über Siligong gesprochen, bevor wir in Wollongong waren“, also das ist ziemlich cool.
Nick Muldoon:
Ich erinnere mich an die frühen Tage, weil ich glaube, du und Rin seid mit [Umi 00:07:08] auf dem Flug zurückgekehrt, und Umi war sechs oder acht Wochen alt.
Dave Elkan:
Ja, Oktober.
Nick Muldoon:
Wenn ich mich nicht irre, habe ich dich bei deiner Mutter abgesetzt, damit du deine Mutter und Ken treffen kannst und das war quasi die Heimatbasis. Und danach waren es ein paar Monate oder so, bis wir dich endlich hier unten hatten. Und ich glaube, du warst bei Liz und mir, als du hergekommen bist...
Dave Elkan:
Ja, wieder für zwei Wochen.
Nick Muldoon:
... noch ein paar Wochen, und wir haben wirklich über die Entstehung dessen gesprochen, was zu der Zeit als Arijea Products bezeichnet wurde, und einer Marke, bei der wir nie geblieben sind. Woran erinnern Sie sich an diese frühen Tage und an den Versuch, das Geschäft auf die Beine zu stellen?
Dave Elkan:
Wenn ich darüber nachdenke, du warst in Coniston, nicht in Coniston, [Carmila 00:07:59], es waren tatsächlich weniger als zwei Wochen, weil wir alle kleine Kinder hatten und es war einfach ein bisschen verrückt. Also ich glaube, Rin und ich haben uns organisiert... wir sind runtergekommen und haben Inspektionen gemacht und wir sind bei dir geblieben, während wir das machen, und dann konnten wir uns einen Platz in Fairy Meadow sichern und sind runtergezogen, also sind wir zu diesem Zeitpunkt ein bisschen hin und her gegangen. Und dann waren es diese sechs Monate, in denen buchstäblich... Ich hatte kein Fahrrad, ich bin einfach zu Fuß zur Arbeit gegangen, was für mich super neu ist. Ich habe immer den Bus genommen oder bin mit dem Fahrrad gefahren.
Dave Elkan:
Einige von Ihnen wissen vielleicht, dass ich nie zur Arbeit gependelt bin und das hoffentlich nie tun muss, und wir haben unser Leben nach einem solchen Konzept gestaltet. Aber ich finde es wirklich toll, ich lebte nur zwei Kilometer zu Fuß von der Arbeit entfernt, und das war mindestens die ersten sechs Monate, bis ich nach Balgownie gezogen bin, aber es war eine großartige Zeit meines Lebens und wir hatten ein brandneues Baby und konzentrierten uns einfach auf das Geschäft und versuchten [Crosstalk 00:09:00] -
Nick Muldoon:
Ich erinnere mich, dass wir in den frühen Tagen wirklich keine Ahnung hatten, was wir gemacht haben. Wir haben einen Bereich durchsucht und gesagt: „Nein, das ist nicht angemessen“, und dann haben wir unsere Aufmerksamkeit etwas anderem zugewandt.
Dave Elkan:
Ja. Wir sind uns ein bisschen im Kreis gejagt. Wir hatten einmal fünf Produkte mit zwei Personen.
Nick Muldoon:
Das ist richtig.
Dave Elkan:
Ich denke, das ist zu viel, aber dank der guten Gespräche mit den Kollegen um uns herum bei IXI, die wir führen konnten... als hätten sie gute Fragen gestellt und ich erinnere mich, dass Rob und Nathan uns fragten: „Worin bist du gut?“ Und ich glaube, es war Rin, der meinte: „Okay, du hast diese App-Idee, an wen wirst du sie vermarkten? Schau dir deine Netzwerke an.“ Und das war es, all diese Pfeile begannen in Richtung Agile zu zeigen.
Nick Muldoon:
Ja, ich glaube, es war diese Idee, die Rin hatte: „Du kannst es bauen und sie werden kommen, oder du kannst herausfinden, welchen Markt und welchen Vertrieb du hast, und was ist das Publikum, das du bereits hast, und wie nutzt du das Publikum, das du bereits in der agilen Softwareentwicklung hast, um dieses Publikum zu gründen und etwas Schwung zu bekommen?“ Und das hat uns wirklich umgehauen und in Schwung gebracht. Wenn ich mich nicht irre, denke ich, dass wir eigentlich... nicht viele Ausgaben gehabt hätten, aber ich glaube, wir hatten im Juni 2016 tatsächlich die Gewinnschwelle erreicht, und es war irgendwie dieser „Hurra“ -Moment, weil wir nicht in den Zug steigen und nach Sydney pendeln mussten, um bei Atlassian zu arbeiten oder so. Wir hatten das Produkt für markttauglich befunden und konnten es irgendwie weiterverfolgen und zur nächsten Phase übergehen.
Dave Elkan:
Das stimmt, ja. In dieser Geschichte steckt auch viel, zum Beispiel, wie wir festgestellt haben, dass das Produkt zum Markt passt und die Schritte dahin und auch viele Erkenntnisse aus dieser Zeit, die ich irgendwann teilen kann, denke ich, aber wir könnten in ein Kaninchenloch gehen, wenn wir uns darauf einlassen. Aber ich erinnere mich sicherlich an gut durchdachte Gespräche, die bei Lamingtons und Tee im Mike Codd-Gebäude auf dem Innovation Campus der University of Wollongong geführt wurden, wo wir angefangen haben. Und das war wirklich nur eine Zeit, um... es fühlte sich anders an als meine vorherige, zu der Zeit 15 Jahre Erfahrung, in der man eigentlich, es okay ist, innezuhalten und zu reden und darüber nachzudenken, was man tut, während es in der Vergangenheit einfach hieß: „Geh, geh, baue dieses Ding.“ Und es ist wie: „Oh, okay“, das war wirklich erfrischend für mich und ich denke, das war ein wirklich guter Schritt, um das zu öffnen, was zur Storymap wurde, was unser erstes wirklich erfolgreiches Produkt war.
Nick Muldoon:
Mm-hmm (bejahend). Sie haben die Lamingtons und Tee erwähnt, es waren wahrscheinlich mindestens 50% unserer Zeit, das Geschäft auf die Beine zu stellen, waren Lamingtons und Tee. Es ging darum, über Dinge zu chatten, keinen Code zu schreiben, wir hatten keine nennenswerten Kunden. Es ging wirklich darum herauszufinden, welche Art von Markt wir verfolgen wollten, welche Lösungen wir anbieten wollten und welche Art von Geschäft wir aufbauen wollten? Das war ein großer Teil unserer Zeit, um es auf die Beine zu stellen.
Dave Elkan:
Absolut. Und für die Zuhörer da draußen, die nicht wissen, was ein Lamington ist, es ist eigentlich ein köstliches Stück Biskuitkuchen, getaucht in Schokoladensauce und dann Kokosnuss, Kokosraspeln, also ich weiß, dass man sie in den USA kaufen kann. Das haben wir bei Atlassian gemacht und sie waren ein großer Erfolg, vor allem, weil sie auch Sahne drin hatten, also wirklich gut für eine Tasse Tee oder Kaffee, was auch immer man nimmt. Aber die Sache ist, dass es eine gute Idee ist, sich mit einem Mitbegründer zusammenzusetzen und viel mehr zu reden, als Sie tippen, das ist die Art von Regel, die ich daraus gezogen habe.
Nick Muldoon:
Es ist interessant, weil es so etwas wie diese Art des Sprechens statt Tippens war, das quasi die Entstehung eines unserer Werte war, auch dieses engagierte System. Und ich glaube nicht, dass Sie Kahnemans Buch zu dieser Zeit gelesen haben, und das kam später, sondern sogar nur diese Idee von: „Nehmen wir uns jetzt einfach die Zeit, um über solche Dinge nachzudenken und sie zu verarbeiten“, und der Kontext [Crosstalk 00:13:09] -
Dave Elkan:
Nein, ich erinnere mich. Entschuldigung, ja. Ich habe 2017 auf dem Lansing Summit auch einen Vortrag über Engaged System gehalten.
Nick Muldoon:
16 oder 17?
Dave Elkan:
16 oder 17, ich kann mich nicht erinnern, welcher es ist.
Nick Muldoon:
'16, weil du '16 nach Barcelona gegangen bist.
Dave Elkan:
Barcelona, und das habe ich dort gemacht, nicht wahr? Ja, also das war früh, als ich Thinking, Fast and Slow gelesen habe, was ich sehr empfehlen kann.
Nick Muldoon:
Und der Kontext dazu, für die Leute, die zuhören: Mitte 2016 hatte Dave eine neun Monate alte Tochter. Meine Tochter war zwei Jahre alt und ich hatte ein Neugeborenes und du solltest... deine Nummer zwei bekommen, oder? Also bauten wir ein Unternehmen auf, als wir gründeten und auch unsere Familien gründeten, also hieß es: „Lass uns alles machen“, in einer neuen Stadt. Wie: „Lass uns alles auf einmal machen.“
Dave Elkan:
Ja, das könntest du genauso gut, oder? Beiß einfach alles ab und reiß das Pflaster ab und fertig. Ich meine, meine Töchter waren nur 18 Monate voneinander entfernt, also diese Art von... Bring es einfach hinter dich. Mach den schwierigen Teil und dann kannst du gehen und dich danach amüsieren, nur ein Scherz. Es ist toll, in jungen Jahren viele Kinder zu haben, ich vermisse diese Zeit wirklich. Aber ja, wir waren ziemlich verrückt, aber wir haben es geschafft.
Nick Muldoon:
Es gab uns auch eine Einschränkung, nicht wahr? Weil wir das Mitternachtsöl nicht verbrennen konnten, konnten wir uns nicht von 05:00 Uhr bis Mitternacht auspeitschen, weil wir einfach nicht die Energie hatten und wir die Kinder ernähren und baden und ab ins Bett und all diese Dinge. Es gab also einen Rhythmus, und jetzt, wo ich darüber nachdenke, ergab sich daraus ein weiterer Wert, der unser Gleichgewicht betraf und die Herstellung von Gleichgewicht in unserem Leben betraf.
Dave Elkan:
Ja, ich erinnere mich, tut mir leid, dass ich unterbreche, eine Tweet-Idee, ich kann sie wahrscheinlich ausgraben, an der ich Stoffwindeln oder Windeln aufgehängt habe... es muss gewesen sein, es war in Balgownie, also muss das nach sechs Monaten gewesen sein. Aber ich habe Windeln rumgehangen und ich muss an dem Tag von zu Hause aus gearbeitet haben oder so, aber das war einfach so, als würde ich mein Leben mit der Arbeit in Einklang bringen. Und ich glaube, es kam zurück mit Arbeit, Privatleben, Familienbalance oder so. Wir würden das auf Arbeitsleben, Familie und soziale Ausgewogenheit ausdehnen, das versuchen wir zu verfolgen.
Nick Muldoon:
Mm-hmm (bejahend). Wie sind wir auf diese Reise rund um die Werte und die Art der Etablierung der Werte gekommen? Wann war das im Leben des Unternehmens?
Dave Elkan:
Ich kann mich an den Ort erinnern, an dem wir waren, wir waren tatsächlich in unserem Büro in der Crown Street, als wir uns wirklich hingesetzt und uns darin zusammenkauerten, also das wäre 2018 gewesen.
Nick Muldoon:
Ich glaube, im November 2018 haben wir unser erstes Easy Agile für Fortgeschrittene abgehalten, und dort haben Sie die Sitzung abgehalten: „Was uns hierher gebracht hat, bringt uns nicht dorthin.“ Zu diesem Zeitpunkt hatten wir also die beiden Produkte, Easy Agile User Story Maps und Easy Agile Roadmaps, und wir hatten unsere Marke von Arijea Products auf Easy Agile umgestellt, um unsere Energie sozusagen auf den Agile-Bereich zu konzentrieren. Wir haben die anderen drei Produkte, die nicht auf Agile ausgerichtet waren, veräußert, also haben wir sie an einen anderen Atlassian Solution Marketplace-Partner verkauft. Ich glaube, da haben wir angefangen, diese Gespräche über die nächste Entwicklung des Unternehmenswachstums zu führen. Dann war es 2019, als wir wieder in der Crown Street waren, zurück im Büro, wo wir dieses Gespräch über die Kodifizierung, Etablierung und Niederschrift unserer Werte führten.
Dave Elkan:
Das ist richtig, und es ist ein sehr wertvoller Prozess, den man durchmachen muss, um wirklich im Alltag innezuhalten und sich wirklich darauf zu konzentrieren. Damit hatte ich immer Probleme, ich habe immer Dinge zu tun, aber wenn du dich einmal aus diesem Prozess herausziehst und herauszoomst und dir das Unternehmen ansiehst und dir das angesehen hast und was dir am Herzen liegt, dann kannst du wirklich anfangen, diese Gespräche zu führen, aber sie zu einer tatsächlichen Sache zu machen. Ich denke, man kann es nicht einfach nebenbei machen, man kann es nicht einfach so gut machen wie andere Dinge, es muss wirklich Priorität haben, wie ich gerne sage. Priorität ist kein Plural, es macht keinen Sinn, wenn es pluralisiert ist, aber das sollte die eine Sache sein, die man unter idealen Umständen tut, als ob man es einfach tut und sich wirklich darauf konzentriert, weil es wirklich schwierig ist.
Dave Elkan:
Und es sollte nicht, ich glaube nicht in einer Sitzung, aber zumindest wenn du es tust, es zu einer ernsten Sache machen, denn wenn es echte Werte sind und du sie lebst, als ob sie einfach ziemlich unveränderlich sind, gehen sie einfach mit dir weiter. Wenn du feststellst, dass du sie nicht lebst, dann solltest du sie dir unbedingt noch einmal ansehen, aber wir hatten das Glück, dass die Werte, die wir vertreten, wahr geblieben sind, und ich habe wirklich das Gefühl, dass ich von all den Unternehmen, in denen ich gearbeitet habe, sogar Atlassian, diese jeden Tag auf ganz unterschiedliche Weise gelebt habe.
Nick Muldoon:
Mm-hmm (bejahend). Also, was sind die Werte, die wir haben? Wir haben über bessere Ausgewogenheit gesprochen, und darüber haben wir ein bisschen gesprochen. Wir haben auch über ein engagiertes System 2 gesprochen, wie dieses System-2-Denken. Was sind unsere Werte?
Dave Elkan:
Sei der Kunde, gib etwas zurück und [Crosstalk 00:18:30] -
Nick Muldoon:
[Crosstalk 00:18:30] war ein großes Thema und verpflichte dich zum Team. Also besser mit Ausgewogenheit, etwas zurückgeben, Kunde sein, über unser Gewicht hinausgehen, Engaged System 2 nutzen und sich als Team engagieren. Kehren Sie zu dem Gespräch zurück, das wir 2017 über das Thema „Geben“ geführt haben. Das war etwas, das wirklich System 2 war. Wie haben wir darüber nachgedacht, der Community etwas zurückzugeben, und was bedeutete das für uns als Unternehmen?
Dave Elkan:
Ich denke, es geht auf das zurück, was Sie zuvor über die Community in San Francisco gesagt haben, die wir erlebt haben, und was wir hier mit Silicon gemacht haben, und das einfach zu einem Schwerpunkt gemacht haben, um der Community etwas zurückzugeben. Es baut sich nicht von selbst auf, also muss die Community aktiv aufgebaut werden, indem jemand seine Hand hochlegen und sie starten muss, und ich denke, das haben wir getan. Seitdem haben wir es vielen anderen Leuten ermöglicht, auf wirklich einfache Weise etwas zurückzugeben, wie zum Beispiel: „Lass uns ein Meetup veranstalten“, „Das ist in Ordnung, hier ist unser Framework, auf dem wir das aufbauen können.“ Und auch einfach die tägliche Kommunikation, die wir untereinander auf unserem Silicon Slack haben, was einfach super wertvoll ist.
Nick Muldoon:
Auch super aktiv.Dave Elkan:
Oh, super aktiv, besonders im Lockdown, da sind viele Leute, die über alle möglichen Dinge reden.
Nick Muldoon:
Ich denke, vielleicht eines der anderen Dinge, also haben Dave und ich das bei Atlassian erlebt, das war diese Idee des Pledge 1%, aber in unserem ersten oder zweiten Jahr mit Easy Agile kamen Atlassian zusammen mit Salesforce und einer Reihe anderer Unternehmen zusammen, um das Fundament für Pledge 1% zu kodifizieren und aufzubauen und andere Unternehmen zu bitten, sich dazu zu verpflichten. Und 2017 haben wir uns verpflichtet, wenn ich mich nicht irre, 1% zu spenden, und jetzt, wo ich schätze, wir spenden quasi 2%, aber was war der Antrieb hinter unserem Versprechen von 1% to Room to Read?
Dave Elkan:
Es ist zum Teil Faulheit, weil ich wirklich ein System für solche Dinge haben möchte und leider ist es schwierig, wenn man ein Unternehmen gründet, die Zeit zu investieren und darüber nachzudenken. Also entschied ich mich für die einfache System-1-Option, die zu dem passt, was wir bei Atlassian erlebt haben, nämlich Room to Read zu unterstützen, was eine großartige Initiative ist, um sicherzustellen, dass junge Frauen, insbesondere in Ländern der Dritten Welt, mindestens eine höhere Ausbildung erhalten, die Grundschule verlassen, in die High School gehen und wenn sie diesen Punkt erreicht haben, ist es viel wahrscheinlicher, dass sie unabhängig sind. Und mit solchen Dingen, wie diesen Investitionen, ist es, als würde man am Anfang neu beginnen und Ländern und Menschen ermöglichen, sich selbst zu helfen. Wenn sie gebildet sind, ist das ein großer Schritt in die richtige Richtung, um sowohl die Überbevölkerung als auch den Klimawandel und all diese Dinge zu bekämpfen, die davon profitieren, dass es diesen Menschen im Leben gut geht.
Nick Muldoon:
Mm-hmm (bejahend). Ja, sie verbessern ständig ihr Schicksal im Leben, richtig? Wie die Erhöhung des Lebensstandards durch Bildung.
Dave Elkan:
Das ist richtig.
Nick Muldoon:
Und wenn wir darüber nachdenken, dass es eines dieser anderen Dinge ist, über unser Gewicht zu schlagen, ich meine, ich erinnere mich, dass wir darüber gesprochen haben, bevor wir unsere Werte aufgeschrieben haben, darauf haben wir wirklich viel Energie konzentriert. Wie Sie bereits erwähnt haben, waren wir zu zweit und wir hatten fünf Produkte auf dem Markt. Ich bin mir nicht ganz sicher, ob das ein gutes Beispiel dafür war, dass wir über unser Gewicht hinaus geschlagen haben, weil wir vielleicht ein bisschen Probleme hatten, aber was sind einige Beispiele dafür, dass wir als kleines Team aus der Region Australien über unser Gewicht geschlagen haben?
Dave Elkan:
Eines unserer Produkte, das wir ursprünglich gebaut haben, war mir wirklich ein Dorn im Auge, es ging ständig kaputt und es spielte nicht meine Stärken aus, was traditionell die Frontend-Entwicklung ist. Danach habe ich mich davon verbrannt und musste die ganze Nacht wach bleiben und das Problem beheben. Ich entschied mich für Apps, die stärker auf das Frontend ausgerichtet sind. Deshalb haben wir Easy Agile User Story Maps und Easy Agile-Programme und Easy Agile Roadmaps hauptsächlich als Frontend-Apps entwickelt. Tatsächlich hatten Easy Agile Roadmaps in den ersten zwei Jahren nicht einmal einen Server, es war nur eine statische Datei in einem Bucket in CloudFront. So funktioniert Atlassian Connect, es ermöglicht dir, Apps auf diese Weise zu hosten, und das kann wirklich nicht kaputt gehen, es bietet im Wesentlichen nur eine andere Sicht auf Jira, aber architektonisch ist es ziemlich einfach. Also konnten wir einfach... das war eine Art, unser Gewicht zu übertreffen, was auch eine bessere Balance ermöglicht, also ergänzen sie sich in dieser Hinsicht irgendwie. Welche anderen Ideen [Crosstalk 00:23:24] -
Nick Muldoon:
Ja, wenn nicht viel schief gehen kann, dann müssen Sie nicht auf Abruf sein und Sie müssen die Dinge nicht außerhalb der Geschäftszeiten reparieren, damit Sie nicht mit verschwommenen Augen und dickem Finger aufwachen und am nächsten Tag einen Bug haben, der das Problem verschlimmert.
Dave Elkan:
Und wenn du die Analogie zu weit treibst, du könntest denken, dass ein Schlag über deinem Gewicht so ist, als ob du jemanden richtig hart schlagen und ihn dann umwerfen kannst, aber das ist eher so, dass du definitiv um den großen [Pelz 00:23:44] rennst. Du lässt dich nicht einmal auf ein Geschwätz ein, du gehst dem nur aus dem Weg. Deshalb haben wir diese Produkte verwendet, und bis vor Kurzem hatten wir tatsächlich Server für sie, und auch hier ist es immer noch sehr einfach, aber sie werden sehr gut überwacht. Wenn also etwas schief geht, haben wir alles im Griff.
Nick Muldoon:
Ich denke, einer der anderen Aspekte in Bezug auf die Technologie, die über unserem Gewicht liegt, ist, dass wir ziemlich oft... Ich denke, vielleicht hast du schon einmal in Bezug auf Room to Read und das Zurückgeben die Faulheit erwähnt, aber wir sind in gewisser Hinsicht faul und wollen einfach Dinge automatisieren. Und ich erinnere mich an den XKCD-Comic, den du teilst, mit dem, wann ist der richtige Zeitpunkt, um etwas zu automatisieren, und wann automatisierst du es, um die Rendite zu erzielen, die du dir wünschst? Aber ich habe das Gefühl, dass wir einige ziemlich gute Entscheidungen darüber getroffen haben, wann Dinge automatisiert werden sollen und sogar darüber, wie wir Kundensupport anbieten oder die alten Tests und Bereitstellungen durchführen, mit Produkten herumgespielt haben, wir haben diese Dinge zu ziemlich guten Zeiten gemacht, sodass wir Produkte an ein globales Publikum von ein paar tausend Kunden liefern können, von Wollongong aus außerhalb der Zeitzone mit diesen Kunden.
Dave Elkan:
Ja. Es ist auch der Zeit voraus, also ich denke, in der Inception Week, was wir jetzt alle fünf Wochen machen, geben wir eine Woche auf, um dem Team den Raum zu geben, neue Dinge zu entdecken. Dabei sind erstaunliche Dinge herausgekommen, die Sie sonst, wenn Sie nur Woche für Woche, Woche für Woche, Woche für Woche, nie wirklich erkennen würden, aber wenn es mir in den Sinn kommt, fällt mir unser Dev-Container ein, der ein Docket-Container ist, der alle Teile enthält, die für die Entwicklung unserer Apps benötigt werden. Sie checken also einfach dieses eine Repository aus, führen ein Skript aus und es richtet Ihre gesamte Entwicklungsumgebung ein. Es ist eine großartige Möglichkeit für das Team, die Tools zu teilen, die ihnen helfen, ihr Gewicht zu übertreffen. Es ist also ein großer Schlag über unserem Gewicht und das kam aus der Inception Week. Ich denke also, dass die Inception Week mehr bietet als alles andere, und auch der Dev-Container ist ein echter Hingucker.
Dave Elkan:
Früher hatten wir so viele Probleme mit einzelnen Versionen dieses oder jenes auf jedem Computer, und jetzt ist das einfach alles weg, es passiert nie wieder, es hat uns seitdem nie wieder getroffen, und ich denke, es ist ein überwältigender Erfolg. Sicher, es braucht einen brandneuen RAM und eine ganz neue CPU, aber das tut es... wir werden es schaffen, als würde es besser werden.Nick Muldoon:
RAM und CPU sind billig, es ist okay.
Dave Elkan:
Du kannst die Zeit nie zurückbekommen, oder?
Nick Muldoon:
Ja, absolut. Ja, wenn wir über diese Dinge nachdenken, wie bewusst waren wir Ihrer Meinung nach in Bezug auf die Werte in unserem Ansatz beim Aufbau und der Skalierung eines Unternehmens im Vergleich zu Dingen, die einfach passiert sind?
Dave Elkan:
Während eines großen Teils der Unternehmensgründung gab es eine Menge Mentalitätskram: „Mach es einfach“, was passieren muss. Ich möchte jedoch zu der Zeit zurückkehren, als wir angefangen haben, alles war Chaos. Ich erinnere mich daran, Anfang 2018, Mitte 2018, wir kamen am Montag rein und fragten uns: „Was machen wir heute? Was ist diese Woche? Schauen wir uns den Backlog an und schauen wir uns das an.“ Und es gab keinerlei Voraussicht.
Nick Muldoon:
Und wir haben ein paar Dinge aus dem Backlog gestrichen und an diesem Wochenende einfach abgearbeitet. Das war es, richtig?
Dave Elkan:
Ja, so ziemlich. Ja, also hast du die Idee vorgeschlagen, es war Anfang des Jahres, es muss 2018 gewesen sein. War es 2019? Wie dem auch sei, lassen Sie uns einfach eine Woche lang Klarheit schaffen, was im Wesentlichen unser interner CI-Raum ist, und einfach eine Reihe von Produkten und Problemen aus dem Weg räumen. Das war das erste Mal, dass wir angefangen haben, uns wirklich zu konzentrieren, denn da wir so viele Produkte hatten, denke ich, dass wir sie zu diesem Zeitpunkt tatsächlich verkauft haben könnten. Ja, ich glaube, das hatten wir auf jeden Fall. Aber [Crosstalk 00:27:28] -
Nick Muldoon:
Aber wir hatten immer noch Roadmaps, Story Maps, Clarity Week, EACS, als ob wir andere interne Systeme hatten, die wir verwendeten, und das Team wuchs tatsächlich über Dave und mich hinaus, und es wuchs. Da waren Jared, Satvik und Rob, und so wuchs auch das Team zu diesem Zeitpunkt. Es gab uns also die Möglichkeit, eine Reihe von Leuten für einen bestimmten Zeitraum, etwa eine Woche, mit einem Problem zu befassen.
Dave Elkan:
Stimmt, und daraus entstand die Idee des Fokus, und wir fingen an, fokussierte Sprints zu machen, also Produktfokus-Sprints, bei denen ein weiteres schreckliches Problem des Überfahrens hervorgehoben wurde. Wenn Sie Ihre Schätzungen überfahren haben, dann müssten Sie in neun Wochen oder so zurückkommen und es war einfach [diabolisch 00:28:12].
Nick Muldoon:Das ist richtig.
Dave Elkan:
Also haben wir [Crosstalk 00:28:14] fallen lassen -
Nick Muldoon:
Was haben wir gemacht? Wir haben zwei Wochen mit Story Maps gearbeitet, zwei Wochen mit Roadmaps, zwei Wochen mit internen Systemen, zwei Wochen mit irgendwas und dann eine Woche mit Inception Week?
Dave Elkan:
Anfangswoche. Ja, ich denke [Crosstalk 00:28:26] -
Nick Muldoon:
Ich kann mich jetzt nicht einmal mehr erinnern, was das andere Ding war.
Dave Elkan:
Insgesamt waren es neun Wochen, nicht wahr?
Nick Muldoon:
Ja.
Dave Elkan:
[Crosstalk 00:28:31] Straßenkarten-
Nick Muldoon:
Wenn Sie es verpasst und nicht versendet haben, sind wir zum nächsten Produkt übergegangen und haben es weiterentwickelt, und dann kamen wir darauf zurück.
Dave Elkan:
In Ewigkeiten entfernt. Und es war super stressig für das Team und das haben wir schnell zunichte gemacht, in der Woche, in der wir flexibler an die Sache herangegangen sind, wo wir das harte Mandat fallen ließen, dass du jetzt Produkte austauschen musst, wir haben sie ein bisschen übergehen lassen und dann haben wir die Storypoints auf die nächsten angepasst, bla, bla, bla. Und dann kratze ich irgendwann an meinem Gedächtnis, aber im Grunde sind wir an einem Punkt angelangt, an dem wir Möglichkeiten eingeführt haben, die lose auf Shape Up von Basecamp basierten, und wir haben eine Menge Dinge daraus übernommen, aber die meisten davon passten nicht wirklich zu unserer Arbeitsweise und unseren Werten.
Nick Muldoon:
Ich meine, dieser ganze Opportunitätszyklus, wir haben uns jetzt drei- oder viermal weiterentwickelt.
Dave Elkan:
Und im Idealfall waren es nur zwei oder vier Wochen Arbeit, und dann machten wir die Inception Week und die Tech Debt Week, und wir haben eine spezielle Tech Debt Week als Mandat. Das haben wir seitdem fallen lassen, und jetzt haben wir vier Wochen Arbeit, einschließlich Tech Debt, und dann haben wir die Inception Week, und das ist irgendwie cool, oder? Als ob wir immer noch das Mandat der Inception Week haben, nicht der Tech Debt Week. Das ist das Letzte; ich denke, die Mandate... weil es wie ein Kickstart für dein Motorrad ist, du musst wirklich einen guten Kick geben und das ist im Grunde das, was wir in den letzten drei Jahren versucht haben, ist, dieses Ding zum Laufen zu bringen. Ich glaube, wir haben...Nick Muldoon:
Aufgebauter Schwung.
Dave Elkan:
Der Motor läuft jetzt... ja. Der Motor läuft jetzt und wir ziehen die Kupplung heraus. Es ist nur so, dass die Mandate langsam wegfallen und das Team seinen eigenen Weg findet, aber ich habe immer noch das Gefühl, dass dieser Zyklus das Wichtigste ist, dass fünf Wochen, in denen wir aufhören, jeder weiß, was passiert. Denn wenn es einfach für immer in die Zukunft hinausläuft, kannst du das nicht in deinem Kopf berechnen, aber du kannst fünf Wochen vorausschauen und sagen: „Ich werde diese Arbeit planen, sie wird nicht bis zu einem N-ten Grad erledigt werden, weil das irgendwie komisch ist“, es ist einfach so: „Lass uns versuchen, das zu erreichen und lass uns ein Stück nach dem anderen abbeißen.“ Dann machen wir eine Pause mit der Inception Week, lassen unserer Kreativität freien Lauf und dann kommen wir in der nächsten Runde darauf zurück.
Nick Muldoon:
Richtig, also muss ich hier Timeout anrufen. Also das ist eine Seitenleiste für alle, die zu Hause zuhören; Dave hat gerade diese Analogie benutzt, wie man das Motorrad anwirft und dann die Kupplung herauszieht. Eines der Dinge, die Dave unglaublich gut kann, ist, dass er sich diese Analogien schnappt und diese Analogien verwendet, um Konzepte zu vereinfachen, die ich sonst für ziemlich komplex halte, und sie zu vereinfachen und wirklich gut zu kommunizieren. Das habe ich noch nie gehört, aber es gibt ein neues, das wir dem Repertoire hinzufügen können, Dave. Ich liebe es.
Dave Elkan:
Danke, Kumpel.
Nick Muldoon:
Was für andere Dinge? Weil ich schätze, wir planen diese Reise über fünfeinhalb Jahre, von Dave und Nick und der Hinzunahme von Satvik und Teagan und Jared und Rob und Brad und ein paar Leute im Laufe der Zeit bis zu dem Punkt, an dem wir heute 27, 28 Leute sind. Was sind einige der anderen Wegmarken, die wir irgendwie durchgemacht haben, die unsere Arbeitsweise verändert oder weiterentwickelt haben? Wie das Easy Agile-Betriebssystem, über das wir in der Vergangenheit gesprochen haben.
Dave Elkan:
Nun, es ist etwas, das wir gerade in der Hinrichtungsebene besprochen haben. Offensichtlich explodiert alles alle sechs Monate und man muss es reparieren, als ob alle sechs Monate eine wichtige Sache passiert, und ich finde, das ist gut und gesund, und das läuft immer wieder auf diese Dinge hinaus. Entweder sind sie intern oder extern und ich habe das Gefühl, dass wir es gerade mit einer externen zu tun haben, auf die ich in diesem Podcast nicht wirklich eingehen möchte, aber ich denke, dass es für das Unternehmen gesund ist, sich an sie anzupassen. Aber sicher, ich denke, in dieser Zeit wirklich zu verstehen, dass es die Menschen sind, die zählen, oder?
Dave Elkan:
Das Geschäft ist da drin, als wäre es eine Sache, aber es ist nichts ohne die Leute, die dafür gearbeitet haben, und es dient den Leuten, die hier arbeiten, sowie den Kunden. Und das ist etwas, woraus wir hervorgegangen sind. Was denkst du, Nick? Wie die kulturellen Aspekte dessen, was wir gebaut haben, was fällt Ihnen auf?
Nick Muldoon:
Ich denke auf jeden Fall, dass es diese Wendepunkte gibt. Ich meine, ich erinnere mich an ein Gespräch mit Jared, als wir in der Crown Street Mall waren, und es war 2019 und wir haben mit dem Team am Küchentisch dort gesprochen, und wir konnten acht Leute an diesen Küchentisch bekommen und wir haben darüber gesprochen, das Team zu vergrößern, um die Gelegenheit zu nutzen und auf Kundenanfragen und all diese Dinge zu antworten. Ich glaube, Jared sagte: „Nun, ich mag es so, wie es ist.“
Nick Muldoon:
Und dann spalte ich zu einem Interview mit Jared vor, das in das fünfjährige Video eingeflossen ist, das wir kurz vor Weihnachten gesehen haben und in dem es um seinen Werdegang ging und wie er sich beruflich und persönlich zusammen mit dem Unternehmen weiterentwickelt und angepasst hat. Ich denke, das ist die Geschichte für uns alle als Teammitglieder, wir waren alle irgendwie zusammen auf einer Reise und wir lernen und passen uns alle zusammen an. Wir leben in vielerlei Hinsicht diesen agilen Ansatz, bei dem wir nachdenken und uns die Zeit nehmen und nachdenken und mit neuen Ansätzen experimentieren, um unsere Arbeit zu erledigen.
Nick Muldoon:
Ich glaube sogar... und wir haben in letzter Zeit darüber gesprochen, was Pace angeht, die erste Version unseres Lern- und Entwicklungsprogramms, in dem wir die Leute finanziell unterstützen wollten, damit sie etwas verfolgen können, worüber sie lernen wollten. Aber wir haben das rausgebracht: „Hey, das war Arbeit für einen Morgen“, wir haben ein L&D herausgebracht, die Leute haben angefangen, das L&D-Programm zu benutzen, und wir nannten es unsere erste Version unseres L&D-Programms, und heute sind wir bei Version, ich weiß nicht, 1.4 oder was auch immer es ist, unseres L&D-Programms. Es gibt viele Dinge, die herausgekommen sind und wir optimieren und verbessern sie im Laufe der Zeit, um sie immer besser und besser an den aktuellen Spielstand innerhalb des Teams anzupassen. Ist das fair?
Dave Elkan:
Ja, ist es. Ja, und ich glaube das; A, ich habe noch nie in einem Unternehmen gearbeitet, das so etwas hat und wo man aktiv dazu ermutigt wird, es zu nutzen, das Geld auszugeben und sich selbst zu verbessern. Wenn Sie sich selbst verbessern, wird das Team besser, wenn das Team besser wird, die Kunden bessere Ergebnisse erzielen und das Unternehmen sich weiter verbessert, und es wird wahrscheinlich ein besserer Ort für Sie sein, um in Zukunft zu arbeiten. Es ist also wirklich eine ganzheitliche Perspektive und nicht engstirnig, sondern kurzsichtig oder konzentriert sich nur auf den Output. Es geht um Output-Ergebnisse und ich denke, das könnte ein weiterer unserer Werte sein. Wenn wir sieben hätten, wären es Ergebnisse über Output. Also wirklich aufzuhören, die Erlaubnis zu haben, innezuhalten und nachzudenken und sich darauf einzustellen und darüber nachzudenken, was Sie erreichen wollen, anstatt einfach blindlings Dinge zu tun.
Dave Elkan:Aus der Sicht eines Entwicklers ist der schnellste Code also der Code, der nicht existiert. Wenn Sie also etwas anders machen können, was nicht 100 Schritte erfordert, oder einfach entscheiden: „Hey, das ist gerade wirklich schwierig, dieser Teil des Codes, an dem wir arbeiten, oder diese Funktion ist wirklich schwierig. Können wir das Feature einfach löschen?“ Und wir haben es sofort gemacht, ich weiß, das klingt ziemlich gewagt, aber ganz ehrlich, diese Art von Diskussion ist wirklich gesund. Ich möchte das Team ermutigen, so zu denken, und ich denke, dass Lernentwicklung auch etwas ist, was man tun kann, um die Leute dazu zu bringen, ihren Werdegang zu betrachten, um ihre Fähigkeiten zu messen und ihnen zu geben, in dieser Hinsicht wirklich... Öl ins Feuer zu gießen und zu sehen, wie sie ihre Fähigkeiten verbessern und ihren Mitmenschen helfen.
Nick Muldoon:
Ja, also führen Sie uns das durch, denn das ist etwas, worüber wir definitiv ein paar Mal gesprochen haben, zum Beispiel, als wir uns Kandidaten angesehen haben und in einem Einstellungsgedränge um Kandidaten über diejenigen gesprochen haben, die sich auf einem bestimmten Weg befinden und von denen wir glauben, dass wir diesen Weg beschleunigen können. Woher kam das?
Dave Elkan:
Woher kommen Gedanken? Ich bin mir nicht sicher, das ist eine gute Frage. Ich könnte es dir nicht sagen, aber ich denke, es ist ziemlich offensichtlich, wenn du dir den Lebenslauf von jemandem ansiehst und du siehst... nun, es ist nichts falsch an Leuten, die lange angestellt sind, aber wenn du mit jemandem sprichst und er nicht wirklich sagen kann, was er in den letzten 10 Jahren gemacht hat und er hat diese eine Position 10 Jahre lang besetzt und er hat nichts wirklich Auffallendes, er kann darüber erzählen, wie er das verbessert hat, das sagt irgendwie viel über diese Person. Vielleicht würden sie reinkommen und einfach an die Küste fahren... sie sind eine Achterbahn, oder? Wenn sie an der Küste fahren, ist das in Ordnung, es ist ihre Entscheidung, aber gleichzeitig suchen wir nach Menschen, die aktiv versuchen, ihre Wirkung durch ihre Arbeit zu vergrößern und ihren Mitmenschen zu helfen. Und das kannst du sehen, du kannst sehen: „Oh, schau. Sie waren in derselben Firma, das ist in Ordnung, aber sie haben diese verschiedenen Rollen übernommen oder sie haben diese Art von Verbesserung in ihrem Ansatz gesehen.“
Nick Muldoon:
Das geht auf diesen Artikel zurück, diesen Financial Review-Artikel, die Rente in der Mitte der Karriere. Das war also ein Artikel, den wir 2016, 2017 veröffentlicht haben müssen, und es ging um eine japanische Bezeichnung, die Rente während der Karriere. Du könntest 20 Jahre Erfahrung in einer Rolle haben oder du könntest 20 erste Jahre Erfahrung haben, und ich denke, schon früh, und vielleicht passiert es heutzutage immer noch, ich denke, das tut es wahrscheinlich, aber es fühlte sich an, als hätten wir 20 Viertel Erfahrung gesammelt. In diesen fünf Jahren gab es immer eine große, neue Herausforderung, die wir in den ersten fünf Jahren lernen und anpassen und in das Unternehmen integrieren mussten. Wir haben also ständig gelernt und uns angepasst, und wir wollten Leute, die sich auf einer ähnlichen Reise befinden und lernen und sich integrieren, sich anpassen und experimentieren.
Dave Elkan:
Ja, das ist definitiv etwas, das man lernen kann, und ich denke, wenn man neue Stars hervorbringt, können sie das einfach bekommen, das tun sie standardmäßig, weil man sie in diese Umgebung gebracht hat. Aber einige Umgebungen, insbesondere ältere Unternehmen, können ziemlich stagnieren und statisch sein, sodass sich das nur in den Lebensläufen der Menschen widerspiegelt. Entweder gibt es irgendeinen Grund, warum das Unternehmen sie nicht befördert oder ihnen die Möglichkeit gibt, ihnen zu folgen, weil wir einen anderen Ansatz verfolgen, bei dem wir den Leuten zu viele Möglichkeiten bieten, glaube ich manchmal, und ich habe gesehen, dass Leute ihre L&D so oft nutzen, dass es sich tatsächlich auf ihren besseren Gleichgewichtswert auswirkt. Ich sage: „Wow, das ist fantastisch, aber vergiss nicht, dass du Kinder hast und helfen musst, auf sie aufzupassen“ und [Crosstalk 00:39:41] -
Nick Muldoon:
Mildere deinen Enthusiasmus, ja.
Dave Elkan:
Ja. Also das ist etwas, nach dem man Ausschau halten sollte.
Nick Muldoon:
Halten Sie inne und denken Sie über fünfeinhalb Jahre nach. Was ist der Zweck des Unternehmens, was ist das Ziel für die nächsten paar Jahre?
Dave Elkan:
Hab Spaß, lerne, was ist mit dir?
Nick Muldoon:
Definitiv lernen.
Dave Elkan:
Bleib im Geschäft.
Nick Muldoon:
Oh, ja. Bleiben Sie im Geschäft, nachhaltiges Wachstum ist immer gut. Ich denke, das ist wichtig. Ja, ich weiß nicht, es ist interessant. Ich habe das Gefühl, an manchen Tagen kann es wirklich Spaß machen und an anderen Tagen macht es überhaupt keinen Spaß. Das liegt wahrscheinlich zum großen Teil daran, als wir damit angefangen haben, waren wir nur für uns selbst und füreinander da, und jetzt habe ich das Gefühl, dass wir in den Diensten eines Teams von Leuten stehen, die selbst für den Kunden da sind, weil wir ein paar Tausend von ihnen haben. Die Verantwortung und die Rechenschaftspflicht haben sich geändert, und die Art und Weise, wie Spaß entsteht, ist heutzutage... es hat Spaß gemacht, Lamingtons zu haben und zu chatten, und heutzutage organisiert normalerweise jemand anderes in der Crew das Event, der oft daran teilnimmt, dass ich mit dem Rest des Teams Spaß und Vergnügen finde, anstatt mir die Zeit nehmen zu können und das zu tun.
Nick Muldoon:
Ich erinnere mich, als wir ein paar Leute von iAccelerate angerufen haben und in die Stadt gefahren sind und in die Stadt gegangen sind und wir haben uns in der Stadt einen Laksa geholt und wir haben eine Schüssel Laksa bekommen. In den letzten 12 Monaten war es schwieriger, das zu tun, angesichts des globalen Umfelds und all dieser Dinge, also hoffen wir, dass wir 2022 ein bisschen mehr davon finden können.
Dave Elkan:
Und vielleicht Ramen. Jetzt gibt es Ramen.
Nick Muldoon:Oh, und es ist großartig, das weißt du.
Dave Elkan:
Ja. Ich denke, wenn wir das, was wir tun, verfeinern und weiter darüber nachdenken, speziell mit den Ingenieuren, verwende ich gerne eine zielorientierte... Ziele sind bei Easy Agile groß, ich denke, Sie sollten ein bisschen über Ziele sprechen, aber wir verwenden sie, um Menschen dabei zu helfen, Dinge zu verfolgen, die sie erreichen wollen, und wir können diese Dinge bis zu einem gewissen Grad an dem ausrichten, was das Unternehmen tut. Dann können Sie tatsächlich gehen und Ihre beruflichen Ziele durch das Unternehmen erreichen, und das Unternehmen ist das Mittel, um dies zu tun, anstatt es draußen tun zu müssen. Das ist wirklich cool, diese Harmonie zu finden, damit sowohl Easy Agile erfolgreich sein kann als auch die Leute, die hier arbeiten, erfolgreich sein können.
Dave Elkan:
Ich denke, es ist tatsächlich ziemlich schwierig, wenn Sie sagen: „Hey, treten Sie einen Schritt zurück, denken Sie darüber nach, was Sie erreichen möchten, geben Sie mir das, und dann werde ich sehen, was ich tun kann, um den Geschäftsverlauf zu ändern und Ihnen dabei zu helfen, das zu erreichen. Was können wir tun? Vielleicht gibt es einen Mittelweg, den wir gemeinsam verfolgen können.“ Und das ist etwas Neues für mich und ich verwende es quasi anstelle von Leistungsbeurteilungen, also stellt sicher, dass ihr eure Ziele erreicht, Leute. [Crosstalk 00:42:44]
Dave Elkan:
Aber ja, du hast auch dafür gesorgt, dass du in der Zeit zurückblicken und dich selbst in der Zukunft sehen willst, um mit dem Team nachzudenken. Wenn sie gegangen sind und weitergemacht haben, [Crosstalk 00:42:56] -
Nick Muldoon:
Oh, ja. Absolut. Ich habe diese Woche sogar mit Elizabeth Cranston gechattet und gesagt: „Ich kann mir vorstellen, dass du in der Zukunft unten in Narooma an der Küste lebst und ich kann runterkommen und mit den Familien Käse und Biccies essen und du schaust über die Bucht auf Narooma oder so, und wir erinnern uns an diese Zeit bei Easy Agile.“ Das kann ich mir absolut vorstellen. Ja, ich finde es großartig und ich denke, nur was die Ziele angeht, die Ziele sind persönlich wichtig, und wir haben in der Vergangenheit viel über Ziele gesprochen, in Bezug auf die langfristige Vision für die Familien und solche Dinge.
Nick Muldoon:
Aber es ist auch für das Unternehmen, ich erinnere mich, dass wir gute Stunden hatten, als wir das Unternehmen auf die Beine gestellt hatten, wir haben sie jedes Jahr überarbeitet, wir haben in den letzten Jahren viel gelernt und uns daran angepasst, wie wir über unsere Ziele und unsere wichtigsten Ergebnisse denken. Und die Tatsache, dass wir sie vierteljährlich verfassen und sie vierteljährlich überprüfen, aber wir haben diese Ziele, die mit einem Geschäftsziel übereinstimmen, das in drei Jahren liegt und das alles irgendwie abläuft. Ich meine, ich denke, wir sind viel reifer in Bezug auf diesen Aspekt unserer... Ich weiß nicht, würde ich strategische Planung sagen? Vision, Zielsetzung über einen längeren Zeitraum? In dieser Hinsicht sind wir heute viel reifer als vor zwei oder drei Jahren. Das ist auch wirklich aufregend. [Crosstalk 00:44:33]
Nick Muldoon:
Kommen Sie zurück zu dem, was Sie zuvor über den Backlog gesagt haben. Wir kamen an einem Montagmorgen rein und fragten uns: „Woran werden wir diese Woche arbeiten?“ Und wir haben über ein paar Jahre gearbeitet, wir haben es so ausgearbeitet, dass „Ah, hier ist die Vision für das Produkt.“ Es war eine längerfristige Sache, und wir haben das erhöht und es heißt nicht: „Hey, was machen wir diesen Monat für das Unternehmen?“ Es heißt jetzt: „Hier ist unsere langfristige Entwicklung für das Unternehmen.“ Wir haben das angehoben, das ist ziemlich aufregend, finde ich.Dave Elkan:
Und gleichzeitig versuchen wir, das Team dazu zu bringen, auch ihre Sichtlinie zu erhöhen.
Nick Muldoon:
mm-hmm (bejahend), mm-hmm (bejahend).
Dave Elkan:
Und schauen Sie weiter weg, aber nicht zu weit. Sie möchten, dass sie sich ansehen, was nächste Woche und auch nächsten Monat passiert, aber auch, was das Ziel ist, was verfolgen wir? Was ist das Gesamtbild? Und ich glaube, das fängt an zu passieren.
Nick Muldoon:
Was ist die Analogie zum Thema Golf, Dave?
Dave Elkan:
Oh. Nein, kannst du es mir sagen? Ich kann mich nicht erinnern.
Nick Muldoon:
Es war diese Analogie zum Golf, also du musst schauen, wo du den Ball schlagen wirst und du musst nach oben schauen. Du willst nicht auf den Abschlag schauen, du willst hinter den Abschlag schauen, damit du... nicht hinter den Abschlag, hinter das Loch, tut mir leid. Du willst hinter das Loch schauen.
Dave Elkan:
Das war nicht meine Analogie, deshalb kann ich mich nicht erinnern, aber ich erinnere mich, dass uns jemand das erzählt hat. Aber es ist gut, als ob es nicht einmal eine Analogie wäre, ist das nicht die wörtliche Sache, die der Golflehrer tun würde? Es ist wie: „Wo schaust du hin?“ Und dann sagen sie: „Oh, ich schaue mir das Loch an.“ „Nein, nein, du musst weiter als das Loch schauen. Schau nach oben, wo der Ball hingehen soll, und dann geht er weg.“
Nick Muldoon:
Ja, erhebe dein Visier.
Dave Elkan:
Erhöhen Sie Ihre Sicht, ja. Und wenn du auf deine Füße schaust, wirst du wahrscheinlich nicht weit kommen, aber wenn du nach oben schaust und Bilanz ziehst, kannst du wahrscheinlich... das ist eigentlich eine Fußball-Analogie, die ich dir geben kann, wie von meinem Fußballtrainer, als ob du mit dem Zeh zeigen musst, wohin der Ball gehen soll. Und das ist einfach das Magische, es funktioniert einfach. Du stellst einfach deinen Fuß neben den Ball und zeigst auf die Ecke des Tores, du willst, dass er reingeht und du trittst ihn, und dann passiert es einfach.
Dave Elkan:Es gibt solche lustigen kleinen Hacks und ich denke, das ist eine Sache mit langfristiger Vision. Wenn Sie ein Unternehmen führen, das diese langfristige Vision und dieses Ziel nicht verfolgt, dann können Sie tatsächlich in mehrere Richtungen gleichzeitig gehen, und Sie werden keine Fortschritte machen. Ich denke, eine gute Analogie, die ich gelesen habe, war wie bei einem Team, wenn man sich vorstellt, dass alle Teammitglieder mit einem Gummiband an einer Stange festgebunden sind und sie alle in verschiedene Richtungen gehen, die Stange wird sich nicht bewegen, weil alle einfach... und das Unternehmen wird statisch und still bleiben. Aber wenn alle einfach in die gleiche Richtung gehen, dann wird es weitergehen.
Nick Muldoon:
Verschiebe es, ja.
Dave Elkan:
Ja. Und das ist etwas, das wir in letzter Zeit abgebissen haben, ist unser Ziel.
Nick Muldoon:
MM-HMM (bejahend), um Teams dabei zu helfen, agil zu sein.
Dave Elkan:
Ja. Das ist einer dieser lustigen Momente, in denen wir darüber reden, und wir haben darüber gesprochen, wir haben uns eine Frist gesetzt, um ein besseres Wort zu sagen, als ob unsere Planungssitzung in ein paar Wochen ansteht, also haben wir uns hingesetzt und darüber gesprochen. Und wir haben uns im Kreis gedreht und versucht herauszufinden, was es heißt, nicht agil zu sein, sondern einfach, was Agile ist? Und wir wissen [unverständlich 00:47:45], aber wir haben versucht, das in Worten zu kodifizieren. Und als du das sagtest, als ob es agil ist, war das irgendwie so... so wie ich es gerne beschreibe, ein umgedrehter A-Moment, was unser Logo ist, wie du es auf Nicks Jacke dort sehen kannst.
Dave Elkan:
Als mir das vorgeschlagen wurde, sagte ich: „Nein, das ist so albern.“ Aber ich sagte: „Oh, aber ich liebe es.“ Und ich sage nicht, dass es albern ist, agil zu sein, aber die Tatsache, dass es so einfach ist, das gefällt mir daran, es ist einfach, es ist einfach, und es gibt eine Menge davon, wenn man sich darauf einlässt.
Nick Muldoon:
Mm-hmm (bejahend). Ja. Ja, warum packen wir es nicht dort ein? Ich denke, das ist ein guter Ort, um zu enden.
Dave Elkan:
Ja.
Nick Muldoon:
Unser Ziel ist es, Teams dabei zu helfen, agil zu sein, und das tun wir für uns selbst, wir versuchen ständig zu lernen und uns anzupassen und mit neuen Dingen zu experimentieren, da wir Easy Agile sind und als unsere Teammitglieder hier sind. Ich hoffe, das war ein nützlicher kleiner Leckerbissen und eine Reise von Dave und mir darüber, wie wir Easy Agile zu diesem Punkt gebracht haben, und über einige der Dinge, die uns beschäftigt haben.
Dave Elkan:
Ja.
Nick Muldoon:
Danke, Dave.
Dave Elkan:
Danke, Nick. Das hat Spaß gemacht.
Nick Muldoon:
Das hat Spaß gemacht. Oh, gut.