[ BETTER TECH LEADERSHIP ]

Geoffrey Teale: Von der Entwicklung zur Führung — Der Weg zur Gestaltung einer technologiegetriebenen Zukunft

[ THE SPEAKERS ]

Meet our hosts & guests

Matt Warcholinski
CO-FOUNDER, BRAINHUB

Matt, Mitbegründer von Brainhub, beschreibt sich selbst als „Serienunternehmer“. Im Laufe seiner Karriere hat Matt mehrere Startups in Deutschland entwickelt und dabei viele Hüte getragen — vom Vermarkter über einen IT-Ingenieur bis hin zum Kundenbetreuer. Als Moderator des Podcasts Better Tech Leadership spricht Matt über das Wachstum erfolgreicher Unternehmen und die Herausforderungen, die sich als Startup-Gründer und Investor stellen.

Geoffrey Teale
Leitender Ingenieur

Geoffrey Teale ist Principal Engineer bei Upvest, wo er die technische Leitung aller technischen Aktivitäten des Unternehmens innehat. Mit einem starken Fokus auf Entwicklererfahrung, API-Governance und Cloud-Infrastruktur sorgt er für nahtlose Integrationen und skalierbare Lösungen. Als erfahrener Softwareingenieur mit fundiertem Fachwissen in Go-, Linux-, Kubernetes- und Cloud-Plattformen spielt Geoffrey eine Schlüsselrolle bei der Gestaltung der Technologiestrategie von Upvest und fördert gleichzeitig eine entwicklerorientierte Kultur.

Transcript

Diese Transkription ist KI-generiert und kann Fehler oder Ungenauigkeiten enthalten.

Matt

Mein Name ist Matt und ich werde mit Geoffrey Teale über die Bedeutung der Vielfalt in Entwicklungsteams und den Aufbau einer starken Entwicklererfahrung sprechen. Hey Geoffrey, das Wichtigste zuerst. Bevor ich zu der Liste der Fragen übergehe, über die wir gesprochen haben, habe ich gesehen, dass Sie kürzlich vom technischen Leiter zum leitenden Produktingenieur gewechselt sind. Und meine erste Frage lautet: Wer ist der leitende Produktingenieur? Worum geht es in dieser Rolle?

Geoffrey Teale

Okay, ich meine, das Erste, was ich sagen muss, ist, dass bei Upvest alle unsere Softwareingenieure Produktingenieure genannt werden. Das hat also damit zu tun, dass wir uns bei allem, was wir tun, auf dieses Produkt konzentrieren. Als Principal Engineer und damit auch als Principal Product Engineer besteht meine Aufgabe eigentlich darin, Projekte in der gesamten technischen Organisation zu betrachten. Sie können sich das also als eine Analogie zu dem vorstellen, was angestellte Ingenieure mit kleinen Gruppen von Teams tun. Das tue ich für die gesamte Organisation. Ich gehöre jetzt zu einer Gruppe innerhalb von upfest, dem Büro des CTO, wo wir uns im Wesentlichen mit den Problemen befassen, die alle Teams betreffen, mit den Interaktionen zwischen Teams, neuen Technologien und leiten Initiativen als unterstützendes Team, damit die anderen Produktentwicklungsteams im Grunde Ideen einbringen und sie so entwickeln können, dass wir wissen, dass sie im gesamten Unternehmen gelten und unsere Compliance-Standards einhalten, das Plattformteam einbeziehen und alles andere tun, was dafür erforderlich ist. ein Hub.

Matt

Okay, danke für die Erklärung, das ist interessantes Zeug. Und während unseres kürzlichen Kurzgesprächs haben wir die kulturellen Unterschiede und die Vielfalt in einem Fintech besprochen, das nicht wirklich vielfältig ist, ich meine die Branche, aber wir besprechen, dass dies ein wichtiges Thema für Sie ist und Sie dieses Paradigma ein wenig ändern möchten. Und ich meine, warum willst du das tun? Welche Herausforderungen siehst du und was tust du, um die vielfältigen Teams zusammenzustellen?

Geoffrey Teale

Okay, ich meine, warum wollen wir das machen? Ich denke, die Gründe für den Wunsch nach Vielfalt in einer Organisation sind im Allgemeinen recht gut, ziemlich bekannt sind die Endbenutzer. Wir haben nicht direkt Endbenutzer, die B2B bis C sind, aber die Leute, die die Ergebnisse unserer Arbeit konsumieren, sind vielfältig. Richtig. Wenn wir also bei der Art und Weise, wie wir Dinge bauen, nur einen Standpunkt vertreten, gibt es Fälle, die wir übersehen können. Wir könnten das Falsche bauen. Und das ist grundlegend sehr wichtig, um ein gutes Produkt zu entwickeln.

Es gibt tatsächlich Dinge, Aspekte, über die die Leute nicht viel sprechen. Wenn Sie Ihre Rekrutierung auf eine sehr kleine Gruppe von Menschen beschränken, erzeugen Sie tatsächlich diese Art von wirtschaftlichem Druck, der die Preise dieser Leute in die Höhe treibt und verschiedene andere Dinge. Ich meine, in Wirklichkeit ist es kontraproduktiv, diese Bereiche zu haben, in denen man nicht viel Vielfalt hat, um ein profitables Unternehmen aufzubauen. Und ich denke, da ist auch das, wie würde ich das sagen? Es gibt diese Realität, dass wir ein Bild von uns selbst als Unternehmen und als Arbeitgeber haben müssen, um zu sagen, dass wir ein guter Arbeitsplatz sind. Und ein guter Arbeitsplatz zu sein bedeutet, offen für alle Arten von Menschen zu sein und sicherzustellen, dass wir alle Arten von Menschen unterstützen. Und wenn Sie nur wieder einen einzigen Standpunkt bei Ihrer Personalbeschaffung haben, Sie nur einen einzigen Satz von Ideen haben, ist es sehr einfach, Dinge zu tun, von denen Sie glauben, dass sie völlig in Ordnung sind, die aber die Leute, die zu uns kommen, abschrecken würden. Und so wird das zu einem säkularen Prozess.

Du könntest für immer versuchen, dich neuen Menschen zu öffnen, aber unbewusst Dinge tun, die dafür getan werden. Aus all diesen Gründen müssen Sie also auf nachhaltige Weise aktiv versuchen, Vielfalt aufzubauen. Also ich meine, das ist der wichtige Aspekt. Was sind die Herausforderungen? Nun, Sie haben bereits erwähnt, dass dies unser Bereich ist, also ist die Konvergenz von Finanzen und Technologie ein besonders, ich würde sagen, nicht vielfältiger Ort, oder? Es gibt zwei Branchen, die eigentlich nicht so vielfältig sind. Und ich meine, ich meine nicht nur, du weißt schon, geschlechtsspezifische Vielfalt.

Es kann auch um ethnische oder kulturelle Vielfalt gehen, um solche Dinge. Und da kann sich eine Spannung aufbauen, also habe ich bereits diese etablierten Praktiken erwähnt, die Sie unbewusst davon abhalten können, andere Menschen mit einzubeziehen. Aber es gibt auch diese Frage, oder? Wenn Sie ein Startup oder sogar ein Scale-up-Unternehmen aufbauen, benötigen Sie wirklich einige Leute mit etwas Erfahrung. Sie können nicht einfach alles aus heiterem Himmel tun. Du musst Leute haben, die wissen, was sie tun. Und das schafft an sich schon ein Problem.

Denn wenn Sie ständig rekrutieren und nach Mitarbeitern mit Erfahrung suchen, können Sie sie nur aus dem Pool von Personen ziehen, die bereits existieren. Und wenn nicht alle Menschen, die es bereits gibt, vielfältig sind, dann ist es sehr schwierig, die Vielfalt zu erhöhen. Eines der Dinge, die ich sehr ernst nehme und das ist eine schwierige Sache, und ich werde nicht sagen, dass wir zu Beginn dieser Reise überhaupt perfekt darin sind, ist, Menschen Möglichkeiten zu bieten, zu Beginn ihrer Karriere einzusteigen. Denn ich denke, das ist wirklich der grundlegende Teil, wenn es darum geht, einen Weg zu einer vielfältigeren Zukunft zu finden. Und das bedeutet eigentlich, dass man bereit sein muss, Menschen weiterzuentwickeln, dass man gut darin sein muss, Mentoring, Training und all diese Dinge zu machen. Und ich denke, Upburst nimmt das sehr ernst und nicht nur meine Abteilung, sondern die Leute, die uns zusammensetzen, nehmen das sehr ernst und setzen alles daran, das zu erreichen. Ich hoffe also tatsächlich, dass wir das schaffen können.

Es geht uns ganz gut. Wir rekrutieren aus vielen Nationen und haben eine ziemlich große Vielfalt, aber zumindest nach Branchenstandards. Aber ich hoffe, dass wir das in Zukunft besser machen können, weil wir diese Dinge umsetzen.

Matt

Und zwei weitere Themen, die wir im Zusammenhang mit deiner vorherigen Rolle besprochen haben, ich würde sagen, es sind Death Rail und Devx. Also verliere ich mich manchmal in all diesen Abkürzungen. Also ich glaube, bei unserem letzten Gespräch habe ich mich verirrt. Aber das sind wirklich interessante Themen. Lassen Sie uns als Entwickler vielleicht mit den Beziehungen zu den Entwicklern beginnen. Könnten Sie mir sagen, warum Sie das getan haben, und mir vielleicht etwas über die Praktiken erzählen, mit denen Sie diese Initiative unterstützt haben?

Geoffrey Teale

Ja. Ich meine, eigentlich ist Developer Relations eine Pflicht, die ich auch in meine neue Rolle mitgebracht habe. Wie Sie schon erwähnt haben, unterscheidet es sich also vom Teil mit der Entwickler-Erfahrung. Ich meine, in verschiedenen Unternehmen fällt das eine in das andere und es herrscht große Verwirrung über diese Dinge. Es überrascht mich also nicht, dass du verwirrt bist. Aber okay, lassen Sie uns über Entwicklerbeziehungen sprechen. Deshalb war ich schon immer jemand, der daran beteiligt war, mit Leuten zu sprechen.

Ich war noch nie ein Ingenieur, der die ganze Zeit mit gesenktem Kopf in einem Raum saß. Ich war schon immer jemand, der mit Leuten gesprochen hat, und es gibt Gründe, warum Sie das in einem Entwicklungskontext tun möchten. Die Gründe sind von Unternehmen zu Unternehmen unterschiedlich. Ich denke, das wichtigste Argument für die meisten Leute, die mit Developer Relations zu tun haben, ist, dass sie für Technologieunternehmen arbeiten und darauf achten müssen, einen Community-Aspekt ihrer Arbeit aufzubauen, Entwickler hinzuziehen, sie zuerst zu engagieren, um ihnen eine wirklich gute Erfahrung zu bieten und das Gefühl zu haben, dass sie unterstützt und unterstützt werden und dass es etwas gibt, das über eine leere Webseite mit Dokumentation hinausgeht, auf die sie sich bei ihrer Arbeit verlassen können. Aber eigentlich ist es auch eine Marketingmaßnahme. Richtig. Vieles davon beinhaltet, auf Konferenzen zu gehen, zu potenziellen Kunden zu gehen und mit ihnen zu sprechen und diese Interaktion auf menschlicher Ebene zu führen, die die technische Interaktion in anderen Unternehmen unterstützt.

Eigentlich ist das eher bei Upbest der Fall. Man könnte sagen, dass es notwendig ist, uns an die technische Marke zu vermarkten. Also haben wir erwähnt, dass wir ein Fintech-Unternehmen sind. Wir sind eigentlich ein Anbieter von Finanzinfrastrukturen. Wir machen Dinge von Geschäft zu Geschäft. All das funktioniert wirklich gut. Aber wenn es um die Rekrutierung von Ingenieuren geht, ist das kein natürlicher Ort, wenn es darum geht, Ihre Marke den Ingenieuren vorzustellen.

Wenn also diese Ingenieure nicht tatsächlich in Unternehmen arbeiten, die uns einsetzen, wären sie unsere Kunden und ihr Bewusstsein für uns ist nicht unbedingt sehr hoch. Das bedeutet, dass ich unter anderem rausgehen und die erwähnten Konferenzen wiederholen muss, nach Möglichkeiten suchen, technische Konferenzen rund um die von uns verwendeten Technologien zu sponsern, öffentliche Reden zu halten, innerhalb der Organisation Aktivitäten wie Open-Source-Projekte zu fördern, bei denen Sie tatsächlich öffentlich demonstrieren können, guten Willen zeigen und auch sagen können, dass dies die Ebene ist, auf der wir als technische Organisation agieren. Unter diesem Gesichtspunkt können Sie es sich also als eine Art Marketing für das Unternehmen in diesem technischen Bereich vorstellen.

Matt

Es ist wie, ich würde es Employer Branding nennen. Es ist, sagen wir etwas, das ich früher genannt habe und wir haben unsere Unternehmen hinzugezogen, aber ich verstehe es absolut. Und was das Devexo-Entwicklererlebnis angeht, dass der Superstar, die Abinoda, es allen zugänglich machen, und ich denke, viele Leute sind begeistert davon. Aber ich frage mich in deinem Fall nur, hast du irgendwelche Ratschläge oder deine eigenen Erfahrungen, was und warum du aus den Devex-Praktiken umsetzen solltest?

Geoffrey Teale

Ja, also ich meine, ich habe ungefähr sieben Jahre im Devex-Bereich gearbeitet, bis ich Mitte dieses Jahres die Rollen gewechselt habe und es tatsächlich Überschneidungen in dem gibt, was ich jetzt mache. Du hast Abhinoda erwähnt. Ich denke, es gibt gerade einen Trend bei Devex, und ich denke, wir könnten später auch auf dieses Thema zurückkommen. Aber die Leute sind im Moment ganz allgemein im Geschäft. Sie sind sehr an Kennzahlen interessiert, sie lassen sich sehr von Kennzahlen leiten. Und es gab eine Reihe von Bemühungen, Abby und die Mitarbeiter von Microsoft, und es sind eine Reihe neuer Produkte auf den Markt gekommen, die sich auf diese Erfassung von Kennzahlen konzentrieren, einen Umfrageaspekt der Entwicklererfahrung. Ich denke, obwohl das alles sehr gut ist, denke ich, dass da die Gefahr besteht, dass das, worum es bei der Entwicklererfahrung geht, auf diese Art von, okay, ich werde das hier messen.

Egal, ob das nun die Zeit ist, bis die Prüfungen abgeschlossen sind, oder Bereitstellungszeiten, solche Dinge, und konzentrieren Sie sich jetzt auf diese Dinge. All diese Dinge können zu nützlichen Ergebnissen führen. Aber eigentlich denke ich, dass man einen Schritt zurücktreten und sagen muss, nun, worum geht es bei der Entwicklererfahrung wirklich? Und für mich geht es darum, eine Situation zu schaffen, in der es für Entwickler einfacher ist, das Richtige zu tun und effizient mit guten Ergebnissen zu arbeiten und dabei glücklich zu sein, als eine Welt zu schaffen, in der wir nur nette Daten produzieren, die einen Manager irgendwo besänftigen. Ich denke, das ist vielleicht ein Thema, auf das ich zurückkommen werde, aber es macht mir ein bisschen Sorgen. Ich meine, meiner Erfahrung nach ist das Wichtigste, was Unternehmen früher nicht getan haben, besonders in größeren Unternehmen, dass, wenn sie Softwareentwicklungsprojekte durchführen oder neue Technologien einsetzen, sie all diese Stakeholder hinzuziehen und sagen, okay, was auch immer wir tun, dieser Prozess muss rechtlich, finanziell, wer auch immer die Stakeholder für dieses Projekt sind, und wir müssen all ihre Bedürfnisse berücksichtigen. Sie gehen weg und erstellen diese Liste von Bedürfnissen und fangen an, unsere technischen Lösungen dafür zu entwickeln und diese zu entwickeln.

In dieser Phase der Anforderungserfassung vergessen sie jedoch oft, dass die Softwareingenieure selbst an diesem Prozess beteiligt sind. Richtig. Es besteht also die Notwendigkeit, Systeme zu entwickeln, die wartbar sind, und darauf aufbauende Prozesse aufzubauen, die wartbar sind. Und vor allem, wenn wir anfangen, über Dinge wie Cloud-Plattformen zu sprechen, an denen ich in den letzten zehn Jahren sehr stark beteiligt war, dass es in dieser Welt Softwareingenieure als Endbenutzer gibt und dass es auch eine Art automatische Gruppe von Wettbewerbern gibt, an die Unternehmen nicht denken. Sie gehen weg und sagen, wir bauen unsere Cloud-Plattform entweder auf einer internen Cloud-Software im Rechenzentrum auf, oder wir nutzen eine öffentliche Cloud und bauen darauf auf und fügen die Teile hinzu, die wir benötigen. Aber die Entwickler denken oft nicht darüber nach, nach welchen Ergebnissen sie wirklich suchen. Also habe ich mir Situationen angesehen, in denen Cloud-Plattformen mit der Idee entwickelt wurden, dass ihre Entwicklungsmethoden dadurch automatisch schneller würden als die altmodischen Unternehmenspraktiken, bei denen sie sechs Monate warten mussten, bis jemand einen Server in ein Rack stellte, damit sie ihren Java-Service aufrufen konnten. Richtig? Und als sie diese Analyse durchführten, als sie diesen Prozess durchliefen, hörten sie nicht auf und dachten, dass all die anderen Prozesse rund um die Bereitstellung einiger Software immer noch dieselben waren wie eh und je.

Zum Beispiel wollte die Organisation immer noch alles überprüfen, eine E-Mail hierher schicken, jemanden an einer Schulung teilnehmen lassen, für die es eine Warteliste von sechs Monaten gibt, bevor er mit der Arbeit beginnen darf, all diese Dinge. Sie haben also nicht die gewünschten Ergebnisse erzielt und die Entwickler, die es verwendeten, waren nicht zufrieden. Und ab einem bestimmten Ausmaß ist die Reaktion auf solche Probleme, wenn Sie es sind, das Problem, wenn Sie Leute daran hindern, Dinge zu tun, dass die Ingenieure zu ihren Managern gehen und sagen, okay, wir können nicht liefern, weil wir mit diesen Leuten nicht weiterkommen. Irgendwann wird der Manager sagen, nun, ich habe ein Budget, ich werde dir einfach direkt ein Konto bei AWS oder Google Cloud kaufen und wir werden Dinge Cloud-nativ machen und wir machen es auf diese Weise. Und dann sind all diese Investitionen und all diese Ideen weg. Es geht also auch darum, die Investitionen, die Sie in diese Dinge tätigen, zu schützen und den Wert tatsächlich zu liefern. Da diese Cloud-Plattform einen echten Mehrwert bot, war die Bereitstellung von Compliance als Produkt von echtem Wert.

Alle möglichen Dinge, die getan werden mussten und die dann von diesen anderen Teams neu erfunden werden müssten. Aber wenn Sie sich nicht auf die Bedürfnisse der Entwickler konzentrieren, wenn Sie sie als Stakeholder nicht berücksichtigen, verpassen Sie all das. Und Sie wissen, dass das für mich der Kern dessen ist, worum es bei der Entwicklererfahrung für mich eigentlich ging.

Matt

Und ich denke, ein weiterer Punkt, der damit zusammenhängt, sind die Metriken, oder? Ich mag die Datenpunkte wirklich, ich verwende die Metriken sehr gerne. Es gibt diese DORA-Metriken, Weltraummetriken, die wirklich hilfreich sind, um Entscheidungen zu treffen. Aber haben Sie in Ihrem Fall bestimmte Metriken, die Sie verwenden, oder etwas, das Ihnen bei der Entscheidungsfindung besonders hilfreich ist?

Geoffrey Teale

Um auf diese vorherige Aussage zurückzukommen, habe ich tatsächlich Dinge wie die Wertstromanalyse verwendet. Es gibt also diese Art von branchenüblichen Metriken. Bei einigen Tools würde man sagen, Zeit bis Hallo, und Zeit, Welt, MySpace, jetzt ist es Zeit für den ersten API-Aufruf. Diese sind ziemlich interessant in dem Sinne, dass sie von den allerersten Schritten sprechen, eigentlich nicht von den ersten Schritten, sondern von den ersten Schritten nach der Entscheidung, ein Produkt zu verwenden. Von der Aussage, okay, ich möchte diese Sache ausprobieren, hin zu dem, dass ich tatsächlich genug von dem Prozess durchlaufen habe, um zu verstehen, wie man die geringste Interaktion mit dem Produkt durchführt. Und das sagt Ihnen viel aus, denn in diesem Zusammenhang habe ich vor der Inbetriebnahme dieser Cloud-Plattform gesprochen, was in mehreren Wochen gemessen wurde, also fast einem Monat, bis Sie zum ersten Mal einen Container auf dieser Cloud-Plattform bereitstellen. Und die meiste Zeit, als wir es analysierten, wurde für Dinge wie E-Mail-Ketten aufgewendet, Wartezeiten zwischen Leuten, die Dinge abholen und auf Genehmigen geklickt haben, und all diese Dinge. Da gab es also viele Möglichkeiten zur Automatisierung.

Und tatsächlich können die Veränderung der Zufriedenheit der Ingenieure, die Veränderung ihrer Fähigkeit, Dinge zu erledigen, und die Veränderung in der Akzeptanz des Produkts gemessen werden. Sie können also sehen, okay, hier sind eine Reihe von Kennzahlen. Ich glaube, ich habe die Hypothese aufgestellt, dass sich die anderen Metriken verbessern werden, wenn ich diese Dinge auf der Grundlage meiner aktuellen Analyse ändere. Und das ist ein wirklich wichtiger Teil jeder Metrik. Und wenn ich sage, dass Kennzahlen eine Gefahr bergen, ist es meiner Meinung nach wirklich leicht, sich vorzumachen, dass Sie empirisch sind. Du gibst eine schöne Zahl an, du siehst, wie sie sich ändert, du meldest sie. Wie ich zu Ihrem Chef gesagt habe, Sie bekommen gutes Feedback, klopfen auf den Kopf und wiederholen diese Schleife immer wieder.

Aber wenn Sie nicht wirklich überprüfen, ob Sie die gewünschten Ergebnisse erzielen, anstatt sich nur diese Zahl zu bewegen, können Sie wirklich auf die falsche Reise geraten. Und es ist so, dass Sie sich selbst vormachen können, dass Sie ein Signal erhalten, das nicht da ist. Und das wiederum bei Entwicklern, insbesondere in großen Unternehmen, war für mich ein Problem, weil Umfragen für Daten sehr nützlich sind. Ich meine, ich schlage vor, rauszugehen und die Leute einfach zu fragen, welche Probleme sie haben. Aber wenn man sehr wenig Signal hat, was oft der Fall ist, ist es schwer, High zu erreichen. Nehmen wir an, beispielsweise bei Umfragen, bei denen Sie nur über sehr wenige Daten verfügen, ist es sehr leicht, dass ein Signal verzerrt wird. Und da muss man wirklich vorsichtig sein.

Und ich denke, es gibt eine Skala, auf der die Analyse von Metriken und in bestimmten Toolfällen, z. B. wenn Sie GitHub oder ähnliches haben, das Abrufen einiger Metriken nützlich sein kann. Aber du musst wirklich wissen, was bestätigen würde, dass diese Änderung dieser Metrik wirklich substanzielle Auswirkungen hat. Und wenn Sie das haben, können Sie vertrauensvoll handeln. Wenn Sie das nicht tun, besteht die Gefahr darin, dass Sie sich selbst etwas vormachen.

Matt

Wenn ich ein Wort verwenden könnte, um das Thema 2023 zu finden, insbesondere in einer großen Technologiebranche, ist Produktivität oder Hyperproduktivität. Ich habe also das Gefühl, dass wir wegen der Entlassungen produktiver werden müssen. Wir brauchen, wir haben weniger Leute, weniger Ressourcen, weniger Geld, um das zu bauen, was wir bauen müssen. Und ich frage mich in Ihrem Fall nur, wie messen Sie, wie tragen Sie dazu bei, innerhalb Ihres Teams zu diesem hyperproduktiven Zustand zu gelangen?

Geoffrey Teale

Also ich meine, ich glaube, es wird viel darüber geredet und du hast die Entlassungen erwähnt. Ich meine, offensichtlich hat ein Teil des Kontextes damit zu tun, KI-Tools einzusetzen. Ich denke, das ist ein sehr interessanter Bereich, nur weil viele glauben, dass dies zu Produktivitätsgewinnen führen wird. Aber die Daten, die ich jetzt veröffentlichen werde, sind sehr isoliert und beziehen sich nur auf bestimmte Aspekte. Wenn wir zum Beispiel über Programmierung sprechen, stellen wir fest, dass die Verwendung eines Tools wie COPILOT die Zeit reduzieren kann, die für die Eingabe einer Lösung benötigt wird. Es nimmt auch etwas Zeit zum Nachdenken in Anspruch. Aber wenn wir zurückblicken und uns ansehen, wie Softwareingenieure ihre Zeit verbringen, ist die Menge an Code, die sie produzieren, tatsächlich relativ gering.

Und dann stellt das Vornehmen von Änderungen an diesem Code nicht wirklich die Gesamtheit ihrer Produktivität dar. Außerdem wird das Gleichgewicht zwischen dem Schreiben von neuem Code und dem Umgang mit Problemen in vorhandenem Code in den meisten Fällen stark auf die Behandlung von Problemen im vorhandenen Code abgewogen. Und einige dieser Tools sind noch nicht sehr gut darin, diese Szenarien zu unterstützen. Es gibt Dinge, die durchkommen, aber sie sind nicht da. Ich denke, wir haben einige aktuelle Studien gesehen, die darauf hindeuten, dass Unternehmen, die diesen Weg eingeschlagen haben, nicht die Rendite erzielt haben, die sie von diesen Dingen erwartet hatten. Und tatsächlich hat vieles davon möglicherweise nur mit Schulungen zur Verwendung dieser Tools und der Anpassung zu tun. Aber auch hier die Entlassungen, die Produktivität.

Aber ich meine, wenn wir nach Produktivität bei Ingenieuren suchen, wenn wir uns tatsächlich die Wissenschaft dieser Dinge ansehen, scheint das, was gerade herauskommt, die Anwendung von Autonomie zu sein, weil Autonomie zu Glück führt. Und tatsächlich ist Glück ein großer Faktor für unsere Produktivität als Menschen. Es gibt also Möglichkeiten, darüber zu sprechen und darüber nachzudenken. Ich habe vor einigen Jahren einen Vortrag darüber gehalten, was mich als Ingenieur glücklich macht, und wir sprechen ein bisschen über Strömungszustände und Strömungszustände, ein Thema, über das, Sie wissen schon, ziemlich modern geworden ist und das direkt mit dieser Idee der Hyperproduktivität verknüpft ist. Aber als Erstes muss gesagt werden, dass Strömungszustände ziemlich selten sind. Richtig? Das ist also keine Situation, in der Sie sich sehr oft befinden.

Wie kommst du da hin? Nun, es hat wirklich mit zwei Dingen zu tun. Es hat damit zu tun, den Raum und die Zeit dafür zu haben und die richtige Art von Herausforderung vor dir zu haben. Wenn Sie also ein Arbeitsumfeld haben, in dem Ihr Tag in viele kleine Abschnitte mit Besprechungen dazwischen aufgeteilt ist, werden Sie nie in einen Raum kommen, in dem Sie einen reibungslosen Ablauf aufrechterhalten können. Das wird nicht passieren. Sie müssen also in Ihrer Organisation Platz schaffen, damit Ingenieure in großen, durchgehenden Blöcken arbeiten können. Sie müssen sich auch mit diesen Herausforderungen befassen.

Eines der Dinge, die ich in der Vergangenheit getan habe, ist, mir technische Aufgaben anzusehen, die am nächsten Tag oder in der kommenden Woche anstehen, und diese technischen Aufgaben zu bewerten und zu sagen, okay, das ist eine Aufgabe, die ziemlich einfach ist. Entwickler X und Y haben das schon eine Million Mal gemacht, aber hey, da drüben ist ein Junior, der das noch nie gemacht hat, und geben diese Aufgabe dieser Person, weil es diese Vorstellung von der Zone der proximalen Entwicklung gibt. Die Herausforderung muss also nicht nur bereit sein und den Platz haben, sondern auch nicht wirklich, wirklich schwierig sein. Es kann nicht etwas sein, an dem du einfach im Schlamm stecken bleiben würdest, aber es muss nur geringfügig über dem liegen, was du regelmäßig tust. Etwas, bei dem Sie tatsächlich darüber nachdenken müssen, was Sie tun, und sich durcharbeiten müssen. Wenn du das hast und die Zeit dafür hast, dann ist es möglich. Es ist nicht garantiert, aber es ist möglich, dass du in diesen Flow-Zustand kommst, der durch viele Dinge gekennzeichnet ist, wie zum Beispiel ein verändertes Zeitempfinden, was auch einer der Gründe ist, warum du einen Tag brauchst, der nicht unterbrochen wird.

Denn wenn man einmal da ist, kann der Tag wie im Fluge vergehen. Wenn Sie eine Situation haben, in der die Herausforderung zu groß ist, macht es keinen Sinn, die Leute dazu zu bringen, auf diese Weise zu arbeiten. Und so greife ich dann auf andere Techniken zurück. Pairing oder Mob-Programmierung hilft Menschen im Allgemeinen dabei, diese Probleme zu überwinden. Sie werden nicht in diesen Flow-Zustand geraten, aber sie werden sie schneller lösen, indem sie mit anderen Leuten diskutieren und das Problem teilen. Wenn die Dinge, an denen du arbeitest, zu banal sind, auch wenn es keine jüngere Person gibt, die das noch nie gemacht hat, kannst du auch anfangen, diese Aufgaben ein wenig spielerisch zu gestalten und ein bisschen Dopamin zu entwerfen. Wenn wir also Engineering-Aufgaben so betrachten, wie Entwickler zum Beispiel mit Komponententests arbeiten, wo sie diese langen Listen von Tests laufen lassen, wenn sie Änderungen vornehmen, wird eine ganze Reihe von Dingen mit roten Kreuzen markiert.

Und dann gibt Ihnen der Prozess, diese Kreuze wiederholt zu entfernen und sie in Zecken zu verwandeln, diesen kleinen Dopaminschub. Anstatt also diese riesige, unhandliche Aufgabe zu sein, die Sie demotiviert, was in der menschlichen Natur liegt, brauchen Sie eine Belohnung, die genauso groß ist wie die vor Ihnen liegende Aufgabe. Das wird zu einem Prozess kleiner Änderungen werden, die euch Feedback geben: Gut gemacht, gut gemacht, gut gemacht, gut gemacht. Und tatsächlich, je mehr Sie das tun, desto mehr wird sich Ihr Dopaminsystem dessen bewusst. So kannst du Menschen auch ohne in Flow zu kommen motivieren, ihre Arbeit ganz einfach zu erledigen. Und tatsächlich werden sich die Leute glücklich fühlen, wenn sie auf diese Weise arbeiten. Es gibt also diese kleinen Tools, die Sie verwenden können.

Matt

Ich spreche wirklich gerne über kontroverse Entscheidungen oder vielleicht über konträre Entscheidungen. Und ich frage mich in Ihrem Fall, ob Sie sich an eine Situation erinnern, in der Sie in einem Produkt- oder Entwicklungsteam eine konträre Entscheidung getroffen haben und am Ende erfolgreich waren. Und kannst du mir davon erzählen? Was waren die gewonnenen Erkenntnisse?

Geoffrey Teale

Ja, also ich meine, ich muss wirklich zurück. Im Laufe meiner Karriere gab es ein paar, aber die wirklich großen, an die ich denke, ich gehe zurück in die 1990er Jahre, als ich nach dem Studium anfing, in Organisationen zu arbeiten, und zu dieser Zeit arbeitete ich für ein wirklich großes multinationales Unternehmen. Sie hatten eine Vielzahl von Computersystemen, Mainframe- und Minicomputer, einiges an Windows-Zeug, aber auch viel proprietäres UNIX-Zeug, das zu der Zeit lief. Und ich fing an, mir einige Projekte anzusehen, und ich war ein bisschen frustriert über die Art der Tools, die wir hatten. Ich hatte Erfahrung mit einigen anderen Dingen im Hochschulkontext und so fing ich einfach an, ich wusste es eigentlich nicht besser, aber ich fing einfach an, alte Hardware, die wir im Büro herumlagen, zu nehmen und Linux darauf laufen zu lassen, und das getan und als Grundlage für einige lokale Entwicklungsarbeiten verwendet zu haben, an denen ich gerade arbeitete. Ich fing an, zu den Leuten zu gehen und zu sagen, hey, wir führen diese lizenzierten Unix-Computer ein. Tatsächlich waren es buchstäblich Zehntausende von Websites, jede mit ihren eigenen Computern.

Das kostet uns etwas. Ich kann mich nicht an die Zahlen erinnern, aber in Großbritannien waren es ungefähr tausend Pfund pro Tag für diese Maschinenlizenzen. Und ich sagte, hey schau, wir könnten das kostenlos machen. Dieses Ding hier macht alle die gleichen Dinge. Die bestehende Logik innerhalb der Abteilung bis hin zu den Verwaltungskammern war natürlich nicht in Ordnung, oder? Wir können dieses Stück freier Software nicht einfach nehmen und benutzen. Das war, sagen wir, in den 90ern, die ganze Linux-Revolution war noch nicht wirklich passiert, aber ich habe darauf gedrängt und dann habe ich herausgefunden, dass ich Verbündete hatte und ich habe gedrängt und wir haben Dinge getestet, wir haben es versucht, wir haben demonstriert und an dem Punkt, als wir anfingen zu demonstrieren, dass das funktioniert und es in Ordnung war und es zuverlässig war, war es zu diesem Zeitpunkt kein Problem Dann fingen die Leute an, sich dafür zu interessieren, weil ich dann anfing zu sagen Ja, das wirkt sich auf unseren Chef und meinen aus und weißt du, für mich klangen tausend Pfund nach viel für diese Leute, es war ihnen egal .

Aber wenn wir anfangen, okay zu sagen, skalieren wir das auf das ganze Land und dann auf die ganze Region und dann auf die ganze Welt. Das hatte eine tiefgreifende Wirkung. Also ich meine nochmal, das ist. Es war insofern umstritten, als meine Manager mir sagten, dass es eine schlechte Idee sei und ich trotzdem darauf drängte, es zu tun, obwohl es nötig war. Noch einmal sage ich, ich wusste es nicht besser, ich war jung und ich denke, es war ein gewisses Maß an Arroganz, darauf zu drängen. Aber es hat mich gelehrt, dass man manchmal nicht mit dem Strom schwimmen und das tun, was alle anderen tun, gute Ergebnisse erzielt. Richtig. Eigentlich musst du innehalten und darüber nachdenken, was du tust.

Und viele Jahre später las ich tatsächlich einen Aufsatz von Paul Graham mit dem Titel Beating the Averages, und er spricht über seine eigenen Erfahrungen mit Technologieentscheidungen und sagte, er verwende etwas namens Common Lisp, um Produkte zu entwickeln. Und er sagte, nun, Leute in anderen Unternehmen, deren Firma von Yahoo gekauft wurde, wollten C verwenden, diese Dinge. Also sagte er, wenn ich mir als Startup ansehe, was ich mache, verstehe ich die Vorteile dessen, was ich tue, und ich verstehe, dass die anderen Leute das nicht sehen. Und wenn ich sehe, dass ein Konkurrent sagt, er stelle C- oder Java-Programmierer ein, dann mache ich mir keine Sorgen. Aber wenn ich sehe, dass sie Technologien einstellen, die dem ähneln, was ich mache, dann mache ich mir Sorgen, weil das bedeutet, dass sie etwas bekommen. Und wenn ich einfach das tue, was alle anderen tun, sind das Wachstum und die Renditen, die ich davon erwarten kann, auf die gleiche Weise eingeschränkt. Ich kann unmöglich hoffen, besser abzuschneiden als sie, aber wenn ich einen besseren Weg finde, sollte ich darauf vertrauen und weitermachen.

Und ich denke, das hat die Entscheidungen geprägt, die ich zu treffen versucht habe, und die Einstellung, die ich versucht habe, Unternehmen zu vermitteln, während ich mich gemeldet habe.

Matt

Apropos Ben Horowitz und die schwierigen Dinge, ich wollte dich nach dem Schwierigsten in deiner Karriere fragen. Nennen Sie wirklich das Schwierigste, was Sie jemals in Ihrer Karriere getan haben, und welche Lehren haben Sie aus der Erfahrung gezogen?

Geoffrey Teale

Beeindruckend. Ich meine, ehrlich gesagt, das mag eine ziemlich offensichtliche Antwort sein, aber das Schwierigste, was ich je tun musste, war, Leute zu entlassen. Und tatsächlich, nach dem 11. September habe ich gearbeitet, dann musste ich eine Menge Leute haben, das Team wurde verkleinert und ich habe viel darüber gelernt, welche Art von Unterstützung man in dieser Situation braucht. Ich war damals noch ziemlich jung, ich hatte so etwas noch nie gemacht und es war psychisch ziemlich schwierig für mich, und ich glaube, es blieb mir überlassen, das Unternehmen zu verlassen, obwohl ich dazu nicht verpflichtet war. Also ich denke, es ist wirklich, weißt du, eine wirklich, wirklich wichtige Sache, darüber nachzudenken. Am Ende des Tages führen schwierige Geschäftsentscheidungen zu echten menschlichen Faktoren, und zwar nicht nur für die Menschen, die direkt betroffen sind, sondern für alle um sie herum. Und ja, ich denke, jede Art von Veränderung in einer Organisation muss sorgfältig überlegt werden.

Und ich glaube nicht, dass es einen richtigen Weg gibt, diese Dinge zu tun, aber es gibt sicherlich gute und schlechte Wege.

Matt

Apropos schwierige Dinge, das ist mein Lieblingsthema. Ich habe also eine Menge Fragen dazu, wie Sie vielleicht bemerkt haben. Aber ich bin immer auf der Suche nach Erkenntnissen für die anderen Führungskräfte. Richtig. Wenn Sie anfangen, CTO zu werden und sich um eine Stelle als CTO bewerben und zuerst CTO, Principal Engineer oder Head of Engineering sind, in Ihrem Fall Ihre Erfahrung als technischer Leiter, als Principal Engineer. Aber es gibt einige Dinge, die von außen nicht sichtbar sind, bevor Sie mit der Arbeit beginnen. Man sieht die Dinge nicht, man sieht die Herausforderungen nicht.

Und vielleicht könntest du als Neuling in der Rolle über die Herausforderungen sprechen, über die nicht so viel diskutiert wird oder von außen nicht gesehen wird.

Geoffrey Teale

Ja. Und ich denke, das ist ziemlich interessant, dass es einige Rollen gibt, leitende Rollen, die keine Führungsrollen sind. Wenn Sie also eine Beziehung zum Linienmanagement haben, ist es sehr einfach, darauf zurückzugreifen. Diktatorisch ist nicht das richtige Wort, aber den Leuten zu sagen, was sie tun sollen, und zu sagen, okay, so werden wir etwas tun. Sie können also, ich meine, Sie können in diese Falle des Mikromanagements tappen, aber Sie können auch die Erwartungen der Menschen stichhaltig wecken und sagen, bitte gehen Sie und erfüllen Sie auch diese Erwartungen. Da besteht ein Gleichgewicht. Aber es gibt Rollen wie meine aktuelle Rolle oder die Arbeit in einem Plattformteam oder als Staff Engineer, in denen Sie nicht unbedingt diese Beziehungen zwischen den einzelnen Führungskräften haben, aber Ihr Job erfordert grundlegend, dass Sie die Art und Weise ändern, wie die Leute an ihre Arbeit herangehen und ihre Arbeit erledigen.

Eines der Dinge dabei ist, dass Sie wirklich gut darin sein müssen, Ihre Argumente vorzubringen. Sie müssen sehr geübt sein und sich sehr sicher sein, wie Sie mit Menschen kommunizieren und welche Argumente Sie vorbringen. Und natürlich kann es Orte geben, an denen es eindeutig in Ihrer Verantwortung liegt, Entscheidungen zu treffen, und Sie müssen sich dabei wohl fühlen. Aber eigentlich diese Gespräche, dieser schriftliche Inhalt, diese Art, wie Sie kommunizieren, dieser Teil des Sagens, okay, ich glaube, wir müssen jetzt diese Änderung vornehmen oder wir müssen diese Sache auf diese Weise tun. Und hier ist der Grund, warum es so schwierig ist, dass Menschen Sie auf dieser Reise begleiten und Sie Ihr Ziel erreichen. Und ich denke, man kann keine Lektionen für Menschen lernen. Selbst wenn Sie es den Leuten sagen, ich weiß nicht, finde ich ein zufälliges Beispiel, sagen wir testgetriebene Entwicklung, die in einigen Unternehmen auch heute noch umstritten ist.

Du kannst den Leuten nicht sagen, oh, übrigens, wenn du das tust, wird es diese zukünftige Situation geben, in der du es von unschätzbarem Wert finden wirst, diese Dinge vor dir zu haben, die dir helfen, die Veränderung, die du vornimmst, zu begleiten. Die Leute müssen das lernen. Man muss also einen Kontext schaffen, in dem die Leute das lernen, und eine Kultur aufbauen, die das unterstützt. Und das ist ein langer, schwieriger Prozess, der mit guten Argumenten beginnt. Ich denke, es kann nicht genug betont werden, wie schwierig das tatsächlich zu erreichen ist, insbesondere in etablierten Organisationen. Wenn man bei Null anfängt und vom ersten Tag an anfangen kann, Menschen zu beeinflussen, insbesondere Menschen ohne Erfahrung, dann ist das ganz einfach. Aber wenn man in eine bestehende Situation kommt, mit einer bestehenden Kultur und bestehenden Ansichten darüber, wie Probleme gelöst werden können, ist es eine wirklich schwierige und nicht schnelle Herausforderung, diese Dinge zu ändern und zu verändern.

Matt

Es ist ein Set, es ist ein Verkaufsprozess, den ich wirklich mag. Wissen Sie, wir müssen den Kontext und die Daten zeigen. Wenn ich zum Beispiel solche Änderungen vornehme, wie die Datenpräsentation, wissen Sie, einige Grafiken, die zeigen und untermauern, was Sie sagen, probieren Sie es aus. Es ist immer sehr hilfreich für mich, denn so mache ich das.

Geoffrey Teale

Ich denke, ich meine, wir sprechen auch ein bisschen darüber, aber ich denke auch, innerhalb von Unternehmen gibt es immer, dass dieser Aspekt des Grases grüner ist. Ich habe die Plattformteams bereits erwähnt. Wenn Leute in ein Unternehmen kommen, sagen sie oft, nun, ich hatte das mal so und das war so gut, wir sollten es so machen. Was immer eine gültige Eingabe ist, oder? Das sollte jeder verstehen, um es zu verstehen. Aber es gibt auch diese Art von Vertrautheit, die im Laufe der Zeit zu Verachtung führt. Und wenn Leute auf andere Unternehmen schauen, sehen sie, ich weiß nicht, eine Präsentation, sie sehen ein Interview wie dieses online, sie nehmen Ideen davon auf, was großartig ist, aber sie sehen auch diese Art von kuratierter Sicht auf ein Unternehmen von außen.

Tatsächlich gehen die Leute davon aus, dass jeder, der in den FAANG-Unternehmen arbeitet, ein Genie ist, das wirklich interessante Arbeit leistet, besonders wenn Sie in größeren Unternehmen tätig sind. Und tatsächlich haben sie eine Menge Leute, die ziemlich banale Arbeit machen, und sehr wenige Leute, die wirklich diese sehr interessanten Dinge tun und diese sehr interessanten Dinge tun und diese Position als Unternehmen zu bekommen, ist zwangsläufig schwierig, wenn man Leute um sich hat. Also diese Vorstellung, dass das Gras auf der anderen Seite grüner ist, alles muss woanders besser gemacht werden. Also sollten wir einfach das kopieren, was sie tun, was in diesen anderen Punkt zurückfließt, indem wir einfach über die Mauer schauen und sagen, oh, jedes andere Unternehmen macht das. Das sollten wir auch tun. Es ist eine wirklich gefährliche Art, Ihr Unternehmen zu gestalten, weil Sie sich Ideen ausleihen können, aber Sie können sich keine Situationen ausleihen. Du bist nicht sie.

Du musst tatsächlich innehalten und nachdenken und sagen, wie trifft das zu? Was ist die richtige Lösung in unserem Unternehmen?

Matt

Das Letzte, was ich Sie fragen wollte, und ich frage alle meine Gäste, ist die Frage nach den Empfehlungen. Kannst du Bücher, Podcasts oder Ressourcenkonferenzen empfehlen, die für dich als Technologieführer vielleicht besonders hilfreich waren?

Geoffrey Teale

Ja, ich meine, ich denke, eines der wichtigsten Dinge, egal in welchem Bereich Sie tätig sind, ist es, zu versuchen, ein bisschen ein Universalgelehrter zu sein. Ich meine, als einzelner Mitwirkender kann man sich sehr spezialisieren und das ist in Ordnung. Aber wenn Sie das sind, wenn Sie führen, wenn Sie versuchen, sich auch in diesem Geschäftsfeld zurechtzufinden, müssen Sie in mehr als einer Domain suchen. Also ich denke, die gibt es, ich meine, für mich spreche ich eigentlich über Devex und solche Dinge. Eines der wichtigsten Bücher, die ich lese, es wird wahrscheinlich nicht so überraschend sein, aber es ist ein Buch mit dem Titel The Design of Everyday Things von Douglas A. Norman, ein Buch, das in der Designbranche einen großen Einfluss hat. Und ich habe etwas über dieses Zeug gelernt, indem ich mit UX-Designern zusammengearbeitet habe und angefangen habe, darüber nachzudenken, wie einige dieser Ideen auf Entwickler zutreffen würden.

Und tatsächlich löst sich diese, du weißt schon, diese ganze, ganze Welt um dasselbe. Allein das Lesen in diesem anderen Raum gab mir eine Fülle von Ideen, wie ich mit den Dingen dort umgehen und über Dinge nachdenken sollte. Ich habe Paul Graham bereits erwähnt. Ich bin Paul Graham vor vielen Jahren als Lisp-Programmierer begegnet. Ich habe seine Bücher über Lisp gelesen, was für moderne Verhältnisse ein relativ obskures Thema ist. Aber dann verfolge ich zufällig seinen Blog und seine Karriere und ich habe bereits mindestens einen Blogbeitrag von ihm erwähnt. Ich glaube, gerade in den letzten Wochen haben wir diese Debatte über den Gründermodus geführt, über die er auch geschrieben hat. Und ob Sie mit diesen Dingen einverstanden sind oder nicht, ich denke, er ist ein interessanter Autor, ein Mann mit interessanten Ideen, und ich finde es immer sehr, sehr gut, dem zu folgen, was er sagt.

Die andere Sache in der Welt der Wirtschaftswissenschaften ist meiner Meinung nach eines der besten Bücher, die ich je gelesen habe, ein Buch mit dem Titel 23 Dinge, die sie Ihnen nicht über Kapital erzählen, weil er seinen Namen nicht aussprechen kann, Hajong Chang, ein koreanischer Ökonom. Es ist tatsächlich ein weiteres wirklich gut geschriebenes Buch, das einige, ich glaube, ziemlich verbreitete Ideen, die Menschen über Wirtschaft haben, zusammenfasst und diese herausfordert, und wenn Sie darüber nachgedacht haben, was. Was ist die wirkliche Situation hier? Und ich fand das ein sehr interessantes Buch, ich glaube, ich könnte den ganzen Tag weitermachen, ich meine, was die Konferenz angeht, leider ist etwas einfach zu Ende gegangen, das früher wirklich wunderbar war, eine Konferenz in den USA namens Strange Loop, also ich glaube, sie machen das nicht mehr, aber das war früher eine wundervolle Sache, weil es die Mischung aus akademischen und technischen Leuten an einem Ort bot und ich hatte eine Fülle großartiger Ideen daraus. Hier in Deutschland gibt es etwas namens Bob Kampf, das passiert in Berlin, das in viel kleinerem Maßstab irgendwie ähnlich ist, ähm. Aber ja, dazu komme ich auch. Ich denke, das wird großartig funktionieren.

Matt

Vielen Dank, Geoffrey für all die Empfehlungen und all die Tipps und deine Gedanken. Ich schätze unseren Vortrag sehr und ich denke auch an unsere Zuhörer. Vielen Dank für heute. Gut, vielen Dank.

Geoffrey Teale

Folge Matt und Leshek weiter.

Explore similar episodes

Mirko Kämpf: Lehre, Vertrauen und Technologie — Eine Reise zu KI-gesteuerter Führung

In dieser Folge erzählt Mirko Kämpf von den unkonventionellen Schritten, die er auf seiner Karrierereise unternommen hat. Er betont, wie wichtig es ist, Systeme zu verstehen und Wissen zu übersetzen. Mirko spricht auch über die Bereitschaft zur KI und betont die Notwendigkeit, sowohl organisatorisch als auch individuell darauf vorbereitet zu sein, und betont das empfindliche Gleichgewicht, das Unternehmen zwischen der Untersuchung neuer Möglichkeiten und der Umsetzung praktischer Lösungen finden müssen.

listen now
Martin Miller: Die Kunst und Wissenschaft des Aufbaus eines erfolgreichen Startups

In dieser Folge sprechen Matt und Martin Miller über die Überbrückung der Kluft zwischen technischen Teams und nicht-technischen Gründern in Startups. Sie sprechen über die Bedeutung von Zusammenarbeit, Kommunikation und realistischen Erwartungen. Martin teilt auch seine Sichtweise auf KI, maschinelles Lernen und wie Unternehmen ihre Investitionsrendite in KI/ML-Initiativen maximieren können.

listen now
Sonny Patel: Vom Entwickler zur Führungskraft — Eine Reise ins Produktmanagement

In dieser Folge interviewt Matt Sonny Patel über die Vermeidung von Burnout und die Förderung technologischer Innovationen in traditionellen Branchen. Sonny Patel berichtet über ihre Erfahrungen bei Microsoft und Amazon und wie diese ihre Ansichten zu Produktmanagement und Teamführung geprägt haben. Sonny spricht auch über die Auswirkungen von KI und wie sie ihre Arbeitsweise verändert hat.

listen now
Michael Frembs: Teamstrukturen meistern — Einblicke in Plattform- und schlanke Teams

In dieser Folge interviewt Leszek Michael Frembs über die Strukturierung und Führung von Tech-Teams. Michael erzählt von seinem Werdegang und beleuchtet wichtige Meilensteine und Lektionen im Bereich Führung. Er gibt Einblicke in den Aufbau effektiver Teams, die Förderung einer Kultur des Vertrauens und der Zusammenarbeit und zeigt, wie wichtig es ist, Teamstrukturen an sich ändernde Bedürfnisse anzupassen.

listen now