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

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

Leszek

Mein Name ist Leszek und ich werde mit Michael Frembs darüber sprechen, wie Tech-Teams strukturiert und geführt werden können, um eine Kultur des Vertrauens und der Zusammenarbeit effektiv zu fördern. Michael, du hattest eine beeindruckende Karriere in der Tech-Branche. Kannst du uns einen kurzen Überblick über deinen Werdegang geben und vielleicht einige wichtige Meilensteine nennen, die dir dabei helfen, dich als Führungskraft weiterzuentwickeln?

Michael Frembs

Ja. Danke. Danke für die Einladung.

Das kann ich machen. Ich werde sehr früh mit dem Kurs beginnen. Mit 10 Jahren habe ich meine erste Website erstellt und mich dazu gebracht, diese Reise in die Softwareentwicklung zu unternehmen. Und auch mit 12 Jahren war ich vier Jahre lang Fußballtrainer. Ich habe einige trainiert, ein paar kleine Kinder, sechs Jahre alt, es war eine tolle Zeit und habe in dieser Zeit dann viele Führungsqualitäten gelernt. Und es hat mir auch geholfen, als ich meinen ersten professionellen Job bei einem kleinen Beratungsunternehmen in München bekam. Ich wurde in weniger als zwei Jahren Teamleiter und konnte die Naht aufbauen und mit ihnen und auch in derselben Firma zusammenarbeiten.

Ich blieb sieben Jahre in derselben Firma wach. Ich habe ein neues Team und ein neues Thema aufgebaut. Es ging um Kubernetes und API und all diese Dinge waren eine coole Gelegenheit für mich, mit verschiedenen Rollen zusammenzuarbeiten, zusammen mit den Mitarbeitern aus dem Betrieb, aber auch zusammen mit Vertrieb und Marketing, um dieses neue Produkt aufzubauen, das wir anbieten. Und danach ging ich zu den Stadtwerken in München.

Es ist also Deutschland, das wäre. Ich habe dort als Cloud-Architekt angefangen. Für mich war es eine Gelegenheit zu sehen, ob ich in diesem Bereich die Expertenrolle übernehmen wollte oder ob ich zurück in den Management-Pfad gehen möchte, weil ich die dritte Person in diesem Team war. Es war ein Team, das neu gegründet wurde, wirklich frisch war die dritte Person. Ich war die rechte Hand des Chefs und ich wusste, dass wir das, wir würden es vermasseln, dieses Team, wir sind im Grunde für die Public-Cloud-Strategie der öffentlichen Versorgungsunternehmen verantwortlich. Und am Ende waren wir es. Das Team wuchs auf 40 Leute an und ich war für 20 von ihnen verantwortlich.

Und jetzt, wo wir sprechen, bin ich. Ich setze den Management-Pfad durch, meine Karriere. Es war also gut für mich, das zu tun. Und danach, gerade jetzt, bin ich bei Interhelp, ich leite die technische Abteilung. Ich leite vier Teams und leite auch Führungskräfte. Es ist das erste Mal für mich in dieser Rolle. Aber ich werde dieses Unternehmen auch verlassen und als Direktor für Softwaretechnik zu eins und eins in mir wechseln.

Leszek

Nett, danke für das Intro. Lass uns über den Aufbau und die Gestaltung von Teams sprechen. Wie gehen Sie beim Aufbau und der Leitung von Teams vor, um sie so effektiv wie möglich zu strukturieren? Vor unserer heutigen Diskussion haben wir ein wenig über den Ansatz von Teamtopologien gesprochen, und ich frage mich, ob Sie etwas Licht darauf werfen können, wie wir Teams strukturieren, vielleicht in irgendeiner Weise darauf Bezug nehmen.

Zu diesem Rahmen.

Michael Frembs

Ja. Um eine kurze Einführung in die Teamtopologie zu geben, kann ich jedem, der es nicht gelesen hat, empfehlen, dieses Buch zu lesen. Es gibt sie schon seit einigen Jahren und sie haben vier verschiedene Teamtypen, nennen wir es Teamtypen, und drei davon. Eines davon ist ein stream-orientiertes Team, es ist im Grunde ein Produktteam und es ist ein autonomes Team, das für die Apps verantwortlich ist, einschließlich ihrer Ausführung, und sie stehen in Kontakt mit dem Endkunden. Und dann gibt es noch das Plattformteam, und die Aufgabe des Plattformteams ist es, die stream-orientierten Teams zu unterstützen, indem es einige Abstraktionen für die darunter liegende Infrastrukturschicht erstellt, um der kognitiven Belastung dieser Teams Rechnung zu tragen. Und meistens tun sie das, indem sie Selfservices anbieten. Und das andere Team ist ein unterstützendes Team, so etwas wie ein internes Beratungsteam.

Wenn Sie also etwas Neues im Unternehmen haben und Sie ihnen dabei helfen möchten, dieses zu erreichen, kann dieses unterstützende Team für kurze Zeit in dieses Team gehen und sie darin coachen, neue Fähigkeiten zu erwerben. Und als ich bei den öffentlichen Versorgungsunternehmen war und mich mit den Dingen, die ich erwähnt habe, wie gesagt, getroffen habe, haben wir ein Team aufgebaut und unsere Aufgabe war es, eine Public-Cloud-Strategie zu entwickeln und sie auch umzusetzen. Im Grunde haben wir also Landezonen geschaffen, in denen alle anderen optimierten Teams, all die anderen Produktteams unsere Landezone verwenden können, um Pfade zu finden, um vielleicht einige Funktionen zu erstellen oder die Datenbanken zu verwenden, all das, was sie brauchten. Also haben wir die kognitive Belastung der anderen Streamlight-Teams reduziert und mussten daher zumindest diese Abstraktionsebene aufbauen. Und das war ein wirklich, wirklich guter Zeitpunkt, um zu sehen, wie das Team wuchs, denn in der ersten Phase des Teams haben wir Cloud-Ingenieure und Cloud-Architekten eingestellt. Im Grunde hatten also alle die gleiche Rolle. Aber das Gute daran ist, dass jeder unterschiedliche Hintergründe hatte.

Wir hatten also einige Cloud-Ingenieure, sie hatten einen Hintergrund in der Softwareentwicklung, was uns in dieser Hinsicht sehr hilft. Die meisten unserer Kunden waren selbst Softwareentwickler. Wir wussten also, was sie brauchen, und wir können es aufbauen. Außerdem verwenden wir Infrastruktur als Code, um all das zu erstellen, all diese Selbstbedienung. Und es ist gut, Leute zu haben, die wissen, wie man guten Code schreibt, die überschaubar, lesbar, wiederverwendbar sind, alles andere und mit Git arbeiten. Und wir hatten andere Cloud-Techniker, sie hatten Erfahrung in den Bereichen Überwachung und Alarmierung, was uns hilft, ein gutes Überwachungssystem aufzubauen und einen guten Überblick über all die Dinge zu haben, die wir getan haben, und auch um den anderen Teams zu helfen, eine gute Überwachung und Alarmierung durchzuführen. Und wir hatten einen anderen Cloud-Ingenieur und sie hatten alle dieselbe Rolle, aber das Gute daran war ein anderer Hintergrund.

Er hatte einen Hintergrund im operativen Bereich und konnte uns helfen, unseren Landesound am Leben zu erhalten und uns eine gute Möglichkeit zu geben, ihn die ganze Zeit laufen zu lassen. Und danach wir. Also, die Stadtwerke in München sind in Deutschland, man würde es eine Kittis-Firma nennen. Also wir, wir hatten eine kritische Infrastruktur, wir sind verantwortlich für Wasser, Gas, den öffentlichen Verkehr und all diesen Kram. Wir hatten also Anforderungen und Sicherheit.

Leszek

Dass alles sicher ist, Zuverlässigkeit, Verfügbarkeit, Sicherheit, all diese Dinge sind wichtig.

Michael Frembs

Alle Dinge sind wichtig, ja, ja. Und zu diesem Zeitpunkt, also normalerweise, würden Sie in diesem Unternehmen ein Sicherheitskonzept zu dem Zeitpunkt erstellen, an dem Sie die Anwendung in die Produktion bringen. Und ich könnte einen meiner Cloud-Techniker beauftragen, mir ein solches Sicherheitskonzept zu schreiben. Aber das Schlimme an dem Sicherheitskonzept ist, dass es nur einen Zeitstempel hat. Es ist zu dem Zeitpunkt, an dem Sie es zum ersten Mal in Produktion bringen. Und das war mir nicht genug. Also habe ich nach einem Cloud-Sicherheitsarchitekten gesucht und ihn engagiert und er sah bei all dem anders aus und er sagte, nun, wir sind in der Public Cloud, also verwenden wir Azure, aber es würde auch mit einem der anderen Cloud-Anbieter funktionieren.

Und er sagte, dass wir aus dieser öffentlichen Cloud viele Informationen über unsere Sicherheitsstufe erhalten, die wir dort haben, und lassen Sie uns diese Informationen verwenden. Wir müssen uns in Echtzeit ein Bild vom Sicherheitsniveau unserer Anwendung machen. Also hat er es auf diese Weise optimiert und es war gut, ihn im Team zu haben, denn ihm war bewusst, dass er sehr motiviert war, das zu tun. Und im Grunde sage ich nur, dass ich über verschiedene Rollen und auch über einige andere Rollen spreche, Personen in eine Rolle zu versetzen, die sie gerne spielen. Wenn ich also einen Cloud-Ingenieur für so etwas wie ein Sicherheitskonzept beauftrage, wird er das tun. Er wird es gut machen, aber er wird es nicht sehr gut oder ausgezeichnet machen. Und auch in verschiedenen Rollen für die DSGVO.

Eine Person, die den ganzen DSGVO-Kram gemacht hat, war unglaublich, weil er es geliebt hat, sich den Gesetzestext anzusehen und ihn für uns zu übersetzen, und wir können das sehr gut machen. Und an dem Punkt, als wir in der ersten Phase die Landezonen eingerichtet haben, haben wir mit unseren Kunden zusammengearbeitet, also mit den anderen Softwareingenieuren, die unser Produkt verwenden, und wir waren sozusagen ein Unterstützungsteam für sie. Wenn wir also zu den Team-Topologien zurückkehren, waren wir sozusagen ein Team, das zu ihnen ging und mit ihnen an unserer Landezone zusammenarbeitete. Und das können Sie in der ersten Phase des Aufbaus tun, weil Sie eine Menge Feedback erhalten und Wissen in diesen Teams haben möchten, dies aber nicht für 10 andere Teams tun können.

Das skaliert nicht. Zu diesem Zeitpunkt wurde uns klar, dass wir in unserem Self-Service und der Vermarktung unseres Verkaufsservices und der Dokumentation unseres Self-Service besser werden müssen. Und an diesem Punkt erfuhr ich von einer neuen Rolle. Es heißt Technischer Redakteur. Es ist eine wirklich tolle Rolle. Der technische Redakteur ist eine Person, die mit uns im Team darüber spricht, was unsere Angebote sind, und er spricht auch mit unseren Stakeholdern, mit den anderen am Stream ausgerichteten Teams, darüber, was sie brauchen. Und hier ist die Schnittstelle zwischen diesen beiden Welten in diesen beiden Teams und er weiß, welche Informationen sie in welcher Form benötigen.

Leszek

Er ist in gewisser Weise ein Moderator, oder?

Michael Frembs

Ja, ja, ein Moderator, aber er hat auch Output. Nun, seine Aufgabe ist es, die Informationen von einem Team zum anderen Team zu bringen und ein Konzept zu erstellen und es könnte in schriftlicher Form sein, es könnte eine Konferenzseite sein, es könnte auch das Git-Repository als Readme sein. Es könnte ein Video sein, das dir ein Tutorial gibt. Es könnte auch ein Podcast sein, in dem Sie einige Informationen teilen. Es war wirklich gut, dass wir skalieren können.

Leszek

Aber ich habe eine grundlegende Frage.

Michael Frembs

Ja?

Leszek

Wie findest du im Grunde, was ist der grundlegende Unterschied zwischen diesen Teams, insbesondere dem Plattformteam und dem stream-orientierten Team? Was sind deine Gedanken dazu? Gibt es einen anderen Polarstern? Wie denkst du philosophisch darüber? Wenn Sie ein optimiertes Team und dieses Plattformteam haben, wie unterscheiden sie sich dann? Wie unterscheiden sie sich von diesem fundamentalen Standpunkt aus?

Michael Frembs

Nun, ich denke, es sind zwei Dinge. Vielleicht ist eine Sache, dass es in einem anderen Stapel ist. Das optimierte Team arbeitet also direkt mit dem Endkunden zusammen. Ich würde also manchmal auch davon ausgehen, dass sie auch eine Weboberfläche oder so etwas in der App haben oder etwas, mit dem der Endkunde arbeiten und es verwenden kann. Das Plattformteam befindet sich am unteren Ende, es ist die meiste Zeit in der Infrastruktur und die internen Kunden können es nutzen. Und meistens bieten sie Verkaufsdienstleistungen an. Nun, beide Teams müssen einen Service anbieten, dessen Bedienung selbsterklärend ist.

Ich denke schon für den Endkunden, aber auch für das Plattformteam. Aber in einem Plattformteam ist es eher ein internes Team, das den am Stream ausgerichteten Teams hilft, ihre Ziele zu erreichen. Sie müssen nicht zu sehr gestresst sein, um alle Anwendungen auszuführen und ihnen dabei zu helfen. So haben wir zum Beispiel für einige Azure-Dienste Terraform-Module erstellt, die vorkonfiguriert waren und sie können dieses Modul einfach verwenden und sie haben nicht im Sinn, wie sie alle Dienste in Azure konfigurieren sollen, weil wir es für sie gemacht haben, wir haben es auf Open-Source-Weise gemacht. Wenn sie also unsere Modelle nicht verwenden möchten, ist es auch in Ordnung, sie direkt zu verwenden, aber sie müssen nicht alle Details über die Azure-Plattform lernen.

Leszek

Wenn wir über die optimierten Teams und Plattformteams sprechen, wie lassen sich diese Unterschiede in diesen beiden Teams in Rekrutierungsstrategien umsetzen? Betrachtest du unterschiedliche Denkweisen? Schaust du dir andere Fähigkeiten an? Das ist ziemlich offensichtlich, aber unterscheiden Sie vielleicht auch die Breite und Tiefe der Fähigkeiten, die diese Personen besitzen? Beeinflusst das, wie du aussiehst und deine Kommunikationsfähigkeiten einschätzt, all das? Wie siehst du aus? Im Grunde versuche ich zu fragen, ob Sie, wenn Sie aus Plattformteams rekrutieren, die Rekrutierung anders angehen, als Sie es sonst mit einem Stream-orientierten Team tun würden?

Michael Frembs

Nun, der Kommunikationsteil ist definitiv der Kommunikationsteil. Als wir bei den Stadtwerken in München waren und die Cloud-Strategie entwickelt haben, mussten wir viel reden. Auf der einen Seite mussten wir also mit den anderen optimierten Teams sprechen, um sie auf den richtigen Weg zu bringen, um die Informationen zu bekommen, wie sie sie nutzen, aber auch um das Feedback von ihnen zu bekommen. Wie schneiden wir mit unserem Self-Service ab? Und nur wenn wir es gut machen, werden sie es benutzen und nur wenn sie es benutzen, haben wir gute Arbeit geleistet. Wenn sie also sagen, dass das, was wir getan haben, ihnen überhaupt nicht geholfen hat, haben wir keine gute Arbeit geleistet. Es ist also wichtig, mit ihnen zu sprechen und das Feedback einzuholen und all diese Dinge, neben den Team-Topologien, es ist auch so, dass wir in der Öffentlichkeit waren, sodass der Stadtlohn ein sehr traditionelles Unternehmen ist und um ihnen zu sagen, hey, wir wechseln zu einer öffentlichen Cloud und diese öffentliche Cloud ist in den USA und wir machen es und es ist eine gute, gute Sache.

Viele Leute waren negativ darüber, weil es zumindest in Deutschland darum geht, was machst du mit unseren Daten? Und sie sind sehr besorgt darüber und all diese Dinge. Und so auf der einen Seite und auf der anderen Seite ist nun, was denkst du über RenderLock? Und wir sind in unserem Fall auf Azure angewiesen und wie können Sie das tun? Also mussten wir viele Leute davon überzeugen, dass wir das Richtige tun. Also habe ich in der Einstellungsphase auch die Denkweise der Leute untersucht, weil wir als Team stark sein mussten. Und wir mussten derselben Meinung sein, denn wenn wir im Team nicht einer Meinung waren, ging alles in die Luft.

Und in der IRIG-Phase habe ich nach der Denkweise gesucht und nach einem Vendor-Login gefragt. Und ich habe gefragt. Nun, ich habe gesagt, dass das Anbieter-Login eine schlechte Sache ist und dass wir es nicht verwenden können, weil wir uns angemeldet haben. Und ich erwarte, dass die andere Person, die den Job vergeben will, sagt, hey, du irrst dich. Wenn die Buchung eine gute Sache ist, wenn Sie sie richtig machen. Und wenn er es nicht getan hat, habe ich ihn nicht engagiert. Aber wenn man für diesen Job so etwas wie ein Evangelist sein muss, um andere Menschen zu überzeugen, dann ist es sehr, sehr wichtig, dass man diese Einstellung hat.

Ich würde nicht sagen, dass es für jedes Bloodfoot-Team auf dieser Welt gilt, aber in diesem Szenario war es so.

Leszek

Ich hab's. Lass uns über Kultur sprechen. Kultur ist oft das, was ein Team ausmacht oder zerstört. Und ich habe mich gefragt, wie gestalten Sie die Kultur in Ihren Teams?

Michael Frembs

Ja, nun, im Grunde möchte ich ein Umfeld haben, in dem alle zusammenarbeiten wollen, um ein gemeinsames Ziel zu erreichen. Ich arbeite gerne zusammen. Ich mag Offenheit, ich mag Konflikte. Ich schätze, wenn sie zu einer besseren Version von etwas führen. Harmonie zu jeder Zeit ist also das Beste, denke ich. Und um das zu erreichen, würde ich sagen, habe ich drei Dinge zu tun. Das erste ist Vertrauen.

Ich mag ein vertrauensvolles Umfeld sehr. Und ich denke, man kann niemandem sagen, dass man mir vertrauen muss.

Das wird nicht funktionieren. Aber Sie können zum Beispiel einer anderen Person aus erster Hand vertrauen. Und meiner Meinung nach hilft Transparenz. Nicht alle Informationen, sondern die meisten Informationen an das Team weiterzugeben, mit dem sie arbeiten können, ehrlich zu dem Team zu sein, authentisch zu sein und auch Rechenschaft abzulegen. Und durch eine Sache weißt du, ob du authentisch bist, und dann ist all das, dass du vorhersehbar bist. Ich denke, wenn die Leute wissen, was du wirklich sein wirst, dann bist du authentisch und du, du baust Vertrauen auf. Und ein weiterer Aspekt beim Aufbau von Vertrauen ist das aktive Zuhören.

Ich mag es, mit meinen Leuten zu reden und zuzuhören, Fragen zu stellen, was, was sie darüber denken. Binden Sie sie in Entscheidungen ein.

Das hilft sehr. Und wenn Sie mit gutem Beispiel vorangehen, wenn Sie ihnen vertrauen, werden sie anfangen, Ihnen zu vertrauen, und sie werden sich gegenseitig im Team vertrauen, um eine Umgebung aufzubauen, bis der zweite Punkt eine echte Delegation ist. Ich bin also der Meinung, dass ich mit Experten zusammenarbeite und nicht der Experte bin. Ich weiß nicht alles, was ein Team macht. In meiner Geschichte war ich zuerst Backend-Ingenieur, dann war ich eher im Bereich der Integrationsinfrastruktur im Frontend-Engineering tätig. Ich habe also alles gesehen, aber ich bin nicht in allem ein Experte. Das wäre nicht richtig.

Aber ich habe die Experten in meinem Team. Also gebe ich ihnen alle Informationen, die ich habe, und sage ihnen, hey, du entscheidest. Und ich stelle die Entscheidung in Frage. Und schauen Sie, ob wir auf dem richtigen oder auf dem falschen Weg sind, aber im Grunde ist das Team eine andere Person, die eine Entscheidung trifft. Und das ermöglicht es auch den Ingenieuren oder den Menschen, zu wachsen. Also gebe ich ihnen Raum zum Wachsen. Ich gebe ihnen Raum, um Fehler zu machen, zu scheitern und neue Dinge über ihre technologischen Dinge zu lernen.

Und die letzte, die dritte, ist erzwungene Intra-Teamarbeit, sodass die Teams gut zusammenarbeiten und sie wissen, wer die Stakeholder sind. Und wenn ich eine Entscheidung treffe, wen muss ich informieren oder wen muss ich fragen oder in all diese Dinge einbeziehen? Und ich mag es, Verbindungen in diesem Stil herzustellen. Ein Beispiel in meinem Job über die Stadtwerke in München: Wir haben dieses ganze Team für die Public-Cloud-Strategie engagiert. Aber das Unternehmen hatte Experten für Netzwerke und Datenbanken und all diese anderen Dinge. Sie können also nicht einfach in dieses Unternehmen gehen und sagen, hey, wir wissen alles besser und wir wissen, wie es geht. Also haben wir virtuelle Teams für jedes Thema zusammengestellt.

Also haben wir ein virtuelles Team für das Netzwerk gegründet, wir haben ein virtuelles Team für Datenbanken und all diese anderen Dinge geschaffen. Wir hatten acht oder neun virtuelle Teams, in denen wir die Experten, die bereits im Unternehmen waren, und die Experten, die wir neu eingestellt haben, gemischt haben, und sie haben zusammengearbeitet. Und das war eines der besten Dinge, die ich in diesem Moment hätte tun können, weil wir alle Informationen erhalten, die wir im Unternehmen hatten, und wir haben auch das Vertrauen und die Akzeptanz dieser Leute bekommen, dass wir das Richtige tun.

Leszek

Das ist wirklich nett. Das ist ein neuer Test.

Machst du es? War es einmalig oder ist es etwas, das Sie in Zukunft gerne verwenden werden, um diese Teams zu mischen? Falls das so ist, falls sich die Gelegenheit ergibt.

Michael Frembs

Wenn sich die Gelegenheit ergibt, werde ich es wieder tun. Bei Interhub bin ich für vier Teams verantwortlich. Und wir haben Ende letzten Jahres, Anfang dieses Jahres, festgestellt, dass wir die Teams neu strukturieren mussten, weil wir neue Produkte bekamen, die wir implementieren mussten. Und ich hätte das Team stabilisieren und die Themen einfach verschieben können, aber ich entschied mich, die Ingenieure umzustellen, sodass ich eine neue Mischung aus diesen Leuten in diesem Team hatte. Es war also auch eine der besseren Entscheidungen, die ich getroffen habe, weil sie danach ein Netzwerk hatten, Verbindungen zu anderen Teams hatten und sie leichter mit ihnen sprechen konnten. Und es vertraute den anderen Jungs und sie hatten die besten Ideen von zwei Teams, sie zusammenzuführen und eine wirklich gute Sache zu haben. Also ich bin, ich bin ein echter Fan der Zusammenarbeit in verschiedenen Stilen.

Leszek

Apropos Zusammenarbeit, arbeiten Ihre Teams remote oder vom Büro aus oder verwenden Sie einen Hybridmodus?

Michael Frembs

Nun, es ist ein Hybridmodus, aber er ist abgelegener, weil es bei den Stadtwerken in München während COVID war und wir von zu Hause aus arbeiten mussten. Wir waren alle in München ansässig, also hätten wir uns im Büro treffen können, aber wir mussten zu Hause bleiben. Jetzt haben wir bei Interhub Leute in München, in Berlin, und wir haben auch Nearshore-Partner in Polen und Rumänien. Also müssen wir, um remote zu arbeiten. Und ja, das ist es, was wir die meiste Zeit tun. Aber für mich ist es wichtig, dass wir uns als Team einmal im Quartal treffen, alle drei Monate, zusammenkommen, Kontakte knüpfen, um alle persönlich zu sehen. Das baut sich auf und lassen Sie uns daran festhalten.

Das baut Vertrauen auf.

Leszek

Absolut. Wenn Sie auf Ihre Karriere zurückblicken, vielleicht auch den Teil, in dem Sie Fußballtrainer waren, aber was sind Ihrer Meinung nach die wichtigsten Lektionen, die Sie über Führung gelernt haben? Weißt du, wir haben darüber gesprochen, du weißt schon, ehrlich zu sein, über Vertrauen, über all diese, diese Dinge. Und ich frage mich, ob Sie quasi, Sie wissen schon, Ihre Erkenntnisse teilen könnten.

Michael Frembs

Ja, ich glaube, ich glaube, ich habe drei Lektionen. Lass uns, lass uns mit der ersten beginnen. Es ist. Wenn du, wenn etwas wirklich wichtig für dich ist und dann etwas wichtig für dich ist, dass es konsequent gemacht wird, dann schaffe eine Rolle dafür. Das war mit dem technischen Redakteur oder dem Cloud-Sicherheitsarchitekten, denn sie werden es tun und sie werden es wahrscheinlich tun. Und wenn Qualität für Sie sehr wichtig ist, sollten Sie eine Rolle für die Qualitätssicherung einrichten. Und erwarten Sie nicht, dass dieser Cloud-Ingenieur, der Software-Ingenieur das in seiner Rolle tut.

Und es ist in Ordnung, dass eine Person mehrere Rollen hat, aber eine Rolle erstellt und dafür verantwortlich ist. Das ist die erste. Die zweite ist, Ihre Kollegen und Teammitglieder wie Erwachsene zu behandeln. Sie werden sich wie Erwachsene verhalten, denn wenn du sie wie Kinder behandelst, die Informationen verstecken und du denkst, du kannst es ihnen nicht sagen, weil sie nervös reagieren oder so, reagieren sie nervös, aber wenn du ihnen die Informationen gibst, wenn du ihnen das Vertrauen gibst und all dem Zeug, werden sie damit arbeiten und sie werden es gut machen. Ich denke, zu viele Führungskräfte, zu viele Unternehmen haben zu viel Angst davor, dass der Schritt beendet wird. Und die letzte ist, scheuen Sie sich nicht, um Rat zu fragen.

Ich war noch sehr jung, als ich geboren wurde, bekam. Ich bekam meine erste Führungsposition und ich hatte viele Ingenieure in meinem Team, die sehr erfahren waren, viel erfahrener als ich. Und der Schlüssel zur Akzeptanz war, sie um Rat zu fragen. Um sie zu fragen, wie würdest du das machen? Und kannst du mir bitte dabei helfen? Außerdem bin ich, wie gesagt, gerade in einem Frontend-Bereich, und das letzte Mal, dass ich Frontends gemacht habe, ich weiß nicht, vor 15 Jahren. Ich habe also keine Ahnung, was die genau machen.

Ich habe das Gefühl, ob wir den richtigen Weg eingeschlagen haben oder nicht. Ja. Aber ich kann, kann nicht ins Detail gehen. Aber wenn Sie sie um Rat fragen, wie sie das machen werden, werden sie sich geschätzt und geschätzt fühlen, und dann werden Sie eine gute Zusammenarbeit haben, eine gute Atmosphäre.

Leszek

Ich hab's. Michael, vielen Dank. Es war mir eine Freude, mit Ihnen zu sprechen. Vielen Dank für Ihre Einblicke und das Teilen Ihrer Erfahrungen und gewonnenen Erkenntnisse. Es war mir ein Vergnügen.

Michael Frembs

Nett. Danke, Lechek. Danke für die Einladung.

Leszek

Folgen Sie Matt und Lechek auf LinkedIn.

‍