Diese Frage beschäftigt mich schon fast obsessiv!

Für mich bedeutet Führung, mit gutem Beispiel voranzugehen.

Dies erfordert ein sehr breites Wissen, die Fähigkeit, sich effektiv in neue Themen einzuarbeiten und auch den Willen, viel Vorarbeit zu leisten, obwohl das Ergebnis ungewiss ist.

Lassen Sie mich eine Geschichte erzählen …

Was ich antraf

Als ich meinen letzten Job als Solution Architect begann, war ich ursprünglich als normaler Mitarbeiter angestellt.
Ich wurde in ein internes Projekt eingebunden, bei dem eine Gruppe von Entwicklern „auf der Bank sass“ und auf ihren Einsatz bei einem Hauptkunden wartete.

Das Projekt war zwei Jahre zuvor gestartet worden und aufgrund der Fluktuation in Richtung Kundenprojekte fehlte eine klare Struktur. Es folgte dem primären Nutzen, Entwickler auf einem gemeinsamen Technologie-Stack zu schulen.

Die Motivation war gering, da die Mitarbeiter auf ihren Einsatz warteten und sich wie eine zweite Wahl fühlten.


Der CTO, der das Projekt kurz davor übernommen hatte, war im Ton und Handeln sehr respektvoll, schien aber damals nicht wirklich motiviert, viel Energie in das Projekt zu investieren.


Als ich im Projekt startete, begann ich den Quellcode zu analysieren, obwohl Frontend und Backend in Sprachen geschrieben waren, die ich seit einiger Zeit nicht mehr angewendet hatte. Ich traf komplexe Konstrukte von Microservices an und Entwickler benötigten Tage, um einfache Aufgaben zu erledigen. Das Frontend war in verschiedene Module aufgeteilt, die jeweils unterschiedliche Design- und Technologieansätze verwendeten.

Das Backend verfolgte einen verkorksten Ansatz zur Implementierung von Microservices, der zu erheblichen Leistungsproblemen geführt hätte, wenn das System jemals in Produktion gegangen wäre.


Es war ein Desaster, in das ich hineingeraten war!

Einarbeitung und Vorbereitung auf Veränderung

Ich begann, die Details mit einigen Entwicklern zu besprechen und führte bald intensive Gespräche mit dem CTO über das Ziel des Projekts.

Der Entwickler, der zuvor die Rolle des Scrum Masters inne hatte, wurde in ein Kundenprojekt abgezogen, so dass jemand seine Rolle übernehmen musste. Die Dailys und Scrum-Zeremonien waren größtenteils technisch getrieben und endeten oft in nerdigen Diskussionen.

Wie würden Sie in so einem Fall vorgehen?

Ich hätte einfach meine Zeit absitzen und einige Konzeptideen in einer Sandbox-Umgebung austesten können.

Raten Sie mal: Ich bin nicht der Typ, der seine Zeit mit Unproduktivität verschwendet.

Die Übernahme

Einen Monat nach meinem Start im Projekt teilte ich dem CTO mit, dass ich die Rolle des Scrum Masters übernehmen und erstmal eine Demonstration geben würde, wie ich Scrum-Zeremonien leite.
Das Scrum-Board war zu der Zeit eine Ansammlung von größtenteils unzusammenhängenden Aufgaben mit einer Sammlung von Ideen im Backlog, die ausprobiert werden sollten.

Während ich die Meetings leitete, führte ich weiterhin Gespräche mit dem CTO. Es brauchte drei Monate, ihn zu überzeugen, den Frontend-Code vollständig neu zu schreiben. In der Zwischenzeit hatte ich eine neue Lösungsarchitektur entworfen und erste Designentwürfe für das zu implementierende Systeme erstellt.
Ich nahm die ursprüngliche Idee des Projekts auf und begann, eine Lösung zu definieren, an der es sich zu arbeiten lohnte.

Der leitende Frontend-Ingenieur des Unternehmens war zum Team gestossen und gemeinsam mit dem CTO entwickelten wir einen ersten Entwurf des Tech-Stacks für das Frontend.

Ich war immer sehr vorsichtig, die Arbeit anderer zu kritisieren, denn als Berater habe ich oft erlebt, wie neue Berater ein Projekt übernahmen und schlecht über ihre Vorgänger sprachen – meist mit dem Ziel, sich selbst hervorzuheben.
Das ist ein hochriskantes Verhalten, denn man muss zuerst beweisen, dass man bessere Arbeit leisten und bessere Ergebnisse erzielen kann als diejenigen vor einem.

Ich habe Softwareentwickler immer als äußerst Competitive erlebt. Alle meine Kollegen hatten studiert und über die Zeit Erfahrungen gesammelt.
Wer bist du, zu kommen und zu kritisieren? Zeige zuerst, dass du es besser kannst!

Grundsätzlich gibt es beim Schreiben von Code kein richtig oder falsch. Viele Aspekte der Softwareentwicklung sind philosophischer Natur. Entscheidend ist, ob die fertige Lösung funktioniert, die Anforderungen erfüllt und im Lifecycle nachhaltig gewartet und weiterentwickelt werden kann.

Wenn Sie ein Projekt erfolgreich führen wollen, müssen Sie die Schlüsselakteure von Ihrer Vision und Ihrem Ansatz überzeugen. Für mich waren dies zunächst der CTO und der leitende Frontend-Entwickler.

Als die Entscheidung, das Frontend neu zu schreiben, beinahe feststand, bezogen wir die Entwickler in die Diskussion ein, um gemeinsam den am besten geeigneten Tech-Stack im Detail festzulegen und sie ins Boot zu holen.

Hätten wir sie mit einer fertigen Entscheidung und einem bereits festgelegten Tech-Stack konfrontiert, wäre das einer Art Diktat gleichgekommen.
Ich selbst mag es nicht, wenn mir Dinge diktiert werden und Manager keine Rücksprache mit mir halten, bevor sie eine Entscheidung treffen – also nehme ich an, dass es anderen genauso geht.

Dennoch ist es eine Kunst, den richtigen Zeitpunkt und die richtige Art der Kommunikation zu finden, um zu vermeiden, dass Unsicherheiten im Team entstehen, indem Dinge postuliert werden, die nie umgesetzt werden.

Der Umgang mit der Vision und Mission

Ich denke, als Führungskraft braucht man eine klare Vorstellung davon, was man erreichen will. Es braucht jedoch ein gutes Gespür für den Zeitpunkt der Kommunikation verschiedener Aspekte an unterschiedliche Stakeholder.

Man braucht eine Vision und eine Mission!
Von dieser muss man so überzeugt sein, dass man Kritik standhalten kann.

Grundsätzlich folgen einem Mitarbeiter, wenn sie die Vision und Mission verstehen können und diese positiv aufnehmen.

Der Umgang mit einem competitiven Umfeld

Wie Sie sich vorstellen können, waren nicht alle Entwickler begeistert von dem neuen Kollegen, der bereit war, den Status Quo in Frage zu stellen.
Wer war er? Warum glaubt er, es besser zu wissen? Was hat er getan, dass er sich das Recht herausnimmt, allen zu sagen, was zu tun ist?
Solche Fragen kamen damals im Team auf.

Das Unternehmen praktiziert eine sehr höfliche Kultur. Ich hatte das auch schon anders erlebt.
Ich mag herausfordernde Diskussionen und bin mir bewusst, dass meine Persönlichkeit teils polarisierend wirkt. Daher war dieser Prozess, die Vision, Mission und den Aktionsplan zu finden, alles andere als reibungslos.

Ich arbeitete zu der Zeit viel und arbeite auch gerne nachts, da es nachts ruhig ist und ich mich ohne Ablenkung durch Nachrichten, Anrufe oder soziale Medien konzentrieren kann. Teammitglieder sahen meine Code-Commits um 3 Uhr morgens und an Wochenenden. Ich machte jedoch klar, dass ich von niemandem erwarte, nachts oder am Wochenende zu arbeiten.

Da die Mitarbeiter im Projektteam auch einem Team in der Linie angehörten, gab es ein Meeting, in dem sie nach dem Status Quo, ihrem Gesamteindruck, Ideen und ähnlichen Themen gefragt wurden. Es gab eine Confluence-Seite, auf der jedes Mitglied seine Punkte notieren konnte.
Einige Zeit später stieß ich auf diese Seite und ging die Kommentare durch. Einige Meinungsführer äußerten starke Kritik an meinem Engagement, stellten infrage, ob ich die anderen und das Management beeindrucken wolle, indem ich nachts und am Wochenende arbeite. Ob ich mich für etwas Besseres halte? Warum der CTO und das Management auf mich hören würden und was mich glauben lässt, dass ich die Rolle eines Managers übernehmen könnte, obwohl ich ein normaler Angestellter des Unternehmens bin?

Ich würde lügen, wenn ich sagen würde, dass mich das nicht persönlich genervet hat, aber ich erwähnte nicht, dass ich von den Gerüchten wusste.
Meine Reaktion war, jeden Einzelnen nach und nach persönlich anzusprechen, sie herauszufordern und die Vision zu kommunizieren, mit dem Fokus, das Team auf eine gemeinsame Mission auszurichten.

Ich betrieb Influencing, um Konsens und Motivation zu schaffen.

Das Team hatte mir ein wahres Junior-Verhalten demonstriert und völlige Ignoranz in Bezug auf politisch korrektes und kluges Handeln gezeigt.

Versuchen Sie niemals, kluge und hart arbeitende Menschen zu mobben, die Sie nicht kennen.
Wenn Sie selbst einen klaren Plan haben und bereit sind, sich dem Wettbewerb zu stellen – nur zu!
Seien Sie mutig und verfechten Sie in 1-zu-1-Diskussionen ihre Position. Nutzen Sie dabei Ihre Kritik klug um Ziele zu erreichen. So bekommen Sie wahrscheinlich Respekt.

Ich schreibe Dinge normalerweise auf, um meinen Standpunkt zu verdeutlichen.

Während einige Manager direkte verbale Kommunikation bevorzugen, mag ich es, Prozesse und getroffene Entscheidungen nachvollziehen zu können.

Die Zukunft wird jeweils zeigen, ob ich richtig lag.

Ich vermeide generell persönliche Angriffe, da ich sie nicht als hilfreich ansehe und mein Interesse liegt ausschließlich darin, ein Thema zu bearbeiten und Lösungen zu finden.
Ich kann jedoch nicht vermeiden, dass sich Menschen persönlich angegriffen fühlen, wenn sie sich mit ihrer Arbeit und Ideen identifizieren, die nicht zu Lösungen führen oder nicht funktionieren!

Als eine der wichtigsten Fähigkeiten betrachte ich die Selbstreflexion. Ich selbst unterziehe meine Aktionen und Ideen permanent Tests und sehe es als wichtig, sich der eigenen Kritik auszusetzen, zu reflektieren und mögliche Fehler zu korrigieren.

Effiziente und zielführende Lösungsfindung

Die Zusammenarbeit mit dem CTO und ihn zu überzeugen, war eine Herausforderung. Dies war möglich, weil er Themem abstrakt betrachtet und genauso wie ich reflektiert. Entscheidungen werden korrigiert, wenn besserer Optionen eingebracht werden, was mir gerade in einem agilen und sich schnell entwickelnden Umfeld wie der IT als zentral erscheint.

Passieren Fehler, werden diese korrigiert, genauso wie eine permanente Optimierung Teil der Umsetzung ist.

Ich bin nicht daran interessiert, meine Ideen anderen aufzuzwingen, und während Konzepte sich entwickeln, ist mein Ansatz nie in Stein gemeißelt. Für viele Themen weiß ich, dass es andere mit tieferem Fachwissen gibt, und ich konsultiere sie ausgiebig, um die beste Lösung zu finden.

Ich halte es für wichtig, in Fällen, in denen die Optionen gleichermaßen funktionieren und die Auswahl nur eine Frage der Präferenz ist, Raum für Kompromisse zu lassen, damit andere zufrieden sind.

Dennoch ist es in der Führung manchmal notwendig, bestimmte Positionen klar zu vertreten. Dies trifft insbesondere zu, wenn sie nicht in das größere Bild der Mission passen. Ein weiterer Grund kann sein, wenn vorhersehbar ist, dass Ansätze in der Zukunft nicht funktionieren werden.

Manchmal ist dies schwierig. Andere hassen einem dafür und alles, aber im Interesse der Sache muss man eine klare Position beziehen.
Wenn man dies nicht tut und das Projekt scheitert, war man Teil des Problems, könnte zur Verantwortung gezogen werden und in bestimmten Fällen sogar Teil eines Delikts werden.

Als Führungskraft ist es wahrscheinlich die größte Herausforderung, die eigene Integrität nicht zu kompromittieren.

Wie leite ich Meetings in moderner Form?

Bei der Leitung von Meetings mit einem Team halte ich es für wichtig, mit etwas Motivierendem zu beginnen – möglicherweise mit Smalltalk, aber auf jeden Fall mit einer Zusammenfassung des Status oder einer Agenda. Die Anwesenden des Meetings müssen wissen, warum sie ihre Zeit im Meeting verbringen.
Insbesondere in Online-Meetings werden sie sich wahrscheinlich nicht konzentrieren, wenn der Zweck nicht klar ist.

Entwickler neigen im Allgemeinen dazu, introvertiert zu sein.

In Scrum-Dailys beispielsweise gibt jeder ein kurzes Statement darüber ab, was erreicht wurde, was geplant ist und welche Hindernisse aufgetreten sind.

Für eine starke Führung setze ich in Meetings bestimmte Techniken ein, um Motivation und Austausch im Team zu provozieren:

• In Online-Meetings ist meine Kamera immer an und ich bin präsent.
• Bei wichtigen Themen oder kritischen Punkten bitte ich die betreffenden Mitarbeitenden, mehr Details zu liefern.
• Lob verteile ich gezielt an 1–2 Teammitglieder, die wichtigen Wert beisteuern und sorge dafür, dass jedes Teammitglied in Rotation gelobt wird.
• Kritik halte ich kurz, um Teammitglieder nicht im Plenum bloßzustellen, und spreche Probleme im Einzelgespräch an.
• Langredner bitte ich, sich kurz zu fassen, um den Fokus auf die relevanten Punkte zu lenken, und fordere eher zurückhaltende Teammitglieder auf, ihre Arbeit näher zu erläutern.
• Themen, die zu stark dominieren verschiebe ich direkt auf separate Meetings, wenn sie mehr Raum benötigen.
• Hintergrundinformationen und Ziele (sowohl kurzfristig als auch langfristig) wiederhole ich gezielt, um sicherzustellen, dass alle im Team an einem Strang ziehen.
• Zusammenarbeit fördere ich aktiv, indem ich Teammitglieder motiviere, gemeinsam zu arbeiten.

Motivation durch erste Erfolge

Das Umschreiben des Frontends zeigte schnell positive Auswirkungen auf das Projekt, und zwei Monate später gingen wir auch das Backend an. Diese Aufgabe war einfacher und schneller umgesetzt als erwartet. Innerhalb eines Monats hatten wir eine funktionierende Lösung mit einem klaren Konzept einer neuen Microservice- und Code Struktur.

Die Motivation im Team wuchs, die Mitglieder nützten öfter Pair-Programming und identifizierten sich stärker mit dem Projekt.

Führung durch Veränderung

Ein wichtiger Schritt war die Umbenennung des Teams: Der Name „Bench“ wurde vollständig abgeschafft, und das Team hieß nun „Innovation“. Mit dieser neuen Bezeichnung steigerten wir das Bewusstsein für die Mission und die Bedeutung der Arbeit jedes Einzelnen.

Etwa zur gleichen Zeit führten wir eine weitere wichtige Änderung in den Scrum-Meetings ein: Jedes Teammitglied übernahm in Rotation die Moderation der Meetings, sodass alle Teammitglieder ihre Präsentationsfähigkeiten in einer vertrauensvollen Umgebung trainieren konnten. Dies stärkte den Teamzusammenhalt und bereitete die Mitglieder darauf vor, ihre Themen auch in Kundenprojekten selbstbewusst vorzustellen.

Motivation durch den weiteren Ausbau und interne Anerkennung

Durch den Erfolg des neu geschriebenen Backends und Frontends nahm das Projekt Form an. Ich begann, Meilensteine für die Feature-Integration zu definieren, diese mit dem Management zu verfeinern und das Team zeitnah zu informieren.

Als das Projekt Gestalt annahm, hatten wir die Gelegenheit, es in den monatlichen Firmenmeetings vorzustellen. Das Team konnte so stolz auf seine Leistungen sein, und das Ziel wurde weiter gefestigt.

Unser Ziel war es, ein ERP-System zu entwickeln und nach einem halben Jahr konnten wir das alte ERP-System auf Unternehmensebene ersetzen. Der Produktionsstart verlief reibungslos und ohne Stress, da das Team hervorragend zusammenarbeitete und sich gegenseitig unterstützte.

Der Umgang mit Mitarbeitern, die nicht performen

Leider gibt es in Projekten auch Situationen, in denen Teammitglieder nicht wie erwartet liefern. Ich neige dazu, Menschen viele Chancen zu geben und auch als Coach zu agieren.

Aber was tun mit Mitarbeitenden, die nicht in der Lage oder nicht willens sind, zu liefern?

Wenn man als Team arbeitet, entsteht eine persönliche Verbindung zu allen Mitgliedern, und normalerweise fällt es schwer, Entscheidungen über die Entlassung eines Teammitglieds zu treffen.

Selbst wenn ein Mitarbeitender loyal zum Unternehmen ist, kann er ein echtes Risko für den Erfolg des Projekts werden und die Motivation des Teams gefährden, wenn er nicht performt.

Ist es für den Mitarbeitenden zielführend in einer Position zu bleiben, in der er ständig Kritik ausgesetzt? Sollte er trotzdem bleiben und wird sich die Situation möglicherweise wieder verbessern?

Wenn ein Team zusammenwächst, werden einige Mitarbeitende Schwierigkeiten haben und möglicherweise nicht mehr ins Team passen.

In größeren Unternehmen kann ein Wechsel zu einem anderen Projekt eine Lösung sein, und ich kenne viele Beispiele, in denen dies für beide Seiten gut funktionierte.

In manchen Fällen, wenn ich sehe, dass ein Mitarbeitender überfordert ist oder seine Motivation verloren hat, gehe ich davon aus, dass er wahrscheinlich frischen Wind und eine neue Herausforderung braucht. Ich weiß, dass eine Kündigung für niemanden einfach ist. Gleichzeitig bietet sie jedoch die Chance, über das Leben nachzudenken und mit neuer Energie frisch zu starten, anstatt in der unbefriedigenden Rolle Zeit zu verlieren.

Während mir das Wohl des Einzelnen wichtig ist, habe ich als Führungskraft auch die Verantwortung für das Wohlbefinden des Teams, dessen Motivation und den Fortschritt des Projekts. Wenn das Team durch ein oder zwei Mitglieder ausgebremst wird, ist es die Pflicht der Führung, den Teamgeist zu schützen.

Vor allem Entwickler sind oft sehr wettbewerbsorientiert und wenn man schwächere Mitglieder im Team behält, riskiert man dafür die Leistungsträger zu verlieren.

Als Führungskraft kommt man immer wieder in die schwierige Situation, Entscheidungen in Bezug auf die Belegschaft treffen. Diejenigen, die das Team verlassen müssen, werden möglicherweise wütend sein, aber die Leistungsträger, die schlussendlich den Projekterfolg sicherstellen, werden am Ende dankbar sein.

Das Entfernen toxischer Teammitglieder kann den Teamgeist und die Produktivität auf ein neues Niveau heben.

Mein Credo lautet: Klare Maßnahmen ergreifen, aber immer fair bleiben.

Der Ansatz der Skalierung

Ich strebte nicht nur die erfolgreiche Implementierung des Systems an. Unser Ziel war es, einen funktionierenden Tech-Stack für die Implementierung ähnlicher Systeme für Kunden zu etablieren.

Während wir noch an dem internen Projekt arbeiteten, entwickelte sich ein Kundenprojekt mit einem ähnlichen Anwendungsfall.

Um den gerade etablierten Tech-Stack weiter auszuarbeiten, teilten wir das Team nicht auf. Wir integrierten beinahe das gesamte Team in das Kundenprojekt und verteilten die Aufgaben beider Projekte.

Die Idee dahinter war, den Entwicklern die Möglichkeit zu geben, ihre Ansätze für bestimmte Themen zu verfeinern.

Mit einem wachsenden Team können so die Entwicklungsaufwände in weiteren ähnlichen Projekte ausgeweitet werden. Ziel war es, davon zu profitieren, das Rad nicht immer wieder neu erfinden zu müssen.

Wir verwendeten denselben Tech-Stack, wodurch viele der Diskussionen, die wir zuvor geführt hatten sich erübrigten. Dies ermöglichte uns, effektiv mit dem zweiten Projekt zu starten und schnell erste Ergebnisse zu präsentieren.

Effizienz durch Repetition vs. experimenteller Umgang mit Neuem

Die meisten Entwickler mögen es nicht, immer wieder dieselben Dinge zu tun. Sie möchten experimentieren und neue Dinge lernen.

In einer modernen Umgebung halte ich es für notwendig, ein Gleichgewicht zwischen dem Erlernen neuer Technologien und der konsequenten Anwendung bewährter Techniken zu finden. Für Mitarbeitende muss klar sein, dass es eine Investition darstellt, der Belegschaft zu erlauben, Neues auszuprobieren. Diese Investition muss sich durch die Anwendung des Fachwissens in Kundenprojekten auszahlen.

In vielen Fällen nahm ich wahr, dass Entwickler mehr daran interessiert sind mit Technologien zu experimentieren, als sich darauf zu konzentrieren, eine funktionierende Lösung oder ein System bereitzustellen.

Wenn ich Technologien erlerne und anwende, konzentriere ich mich immer darauf, ein Problem zu lösen und eine funktionierende Lösung zu liefern. Möglicherweise ist dafür mein unternehmerischer Geist verantwortlich.

Skalierung von Ressourcen

Durch die parallele Nutzung desselben Teams für zwei Projekte konnten wir Ressourcen dynamisch zuteilen.

Wie es bei allen Kundenprojekten der Fall ist, benötigt man in Richtung Produktionsstart mehr Ressourcen. Durch diesen Ansatz konnten wir die Ressourcen entsprechend umschichten, um Engpässe zu vermeiden.

Wenn ich interne Projekte mit Kundenprojekten vergleiche, habe ich festgestellt, dass die Teammitglieder bei Kundenprojekten mehr Professionalität zeigen.

Für mich ist es eine Frage der Professionalität, interne Projekte mit derselben Hingabe zu behandeln wie Projekte für Kunden, auch wenn die Umgebung familiärer ist.

Nach einem Jahr hatten wir ein starkes Team am Start und es war interessant zu sehen, wie sich die verschiedenen Mitglieder in ihren Bereichen entwickelten.

Wir hatten Experten für bestimmte Themen genauso wie Mitglieder, die sich darauf konzentrierten, neue Teammitglieder und Juniors einzuarbeiten und zu coachen.

Anfangs hatten wir nur einen Designer und einen DevOps-Ingenieur im Team.

Es war eine große Erleichterung für diese Mitarbeitenden, als ein zusätzlicher Designer und ein weiterer DevOps-Ingenieur dem Team beitraten. Kollegen für einen Austausch in seinem Fachgebiet zu haben, sehe ich als sehr wertvoll.

Eine Herausforderung blieb jedoch bestehen: Entwickler zu finden, die sich für den gesamten Überblick über das Projekt interessierten, eine marktorientierte Perspektive einnahmen und Ideen für neue Funktionen des Produkts entwickelten. In all meinen Projekten habe ich nur wenige Kollegen gefunden, die diese Themen abdecken konnten.

Während ich an der UI/UX des internen Projekts arbeitete, erklärte mir der Designer, dass die Designs komplex geworden seien und es schwierig sei, aufgrund der vielen verschiedenen Designs den Überblick zu behalten.

Das stimmte sicherlich, doch zusätzlich hatte ich noch den Frontend- und Backend-Code sowie das Cloud-Infrastruktur-Setup zu bewältigen, was die Komplexität nochmals erhöhte. Darüber hinaus arbeitete ich an Konzepten für eine Markteinführungsstrategie und schrieb Akzeptanzkriterien, um die gesamten Projektanforderungen im Detail zu beschreiben.

Die Komplexität in IT-Projekten ist in modernen Umgebungen sehr hoch und es ist viel Wissen erforderlich, um die richtigen Entscheidungen zu treffen und Systeme erfolgreich abzuschliessen.

Für das Team wurden beide Projekte letztendlich große Erfolgsgeschichten. Innerhalb von weniger als zwei Jahren hatten wir in beiden Projekten marktfähige MVPs fertiggestellt.
Diejenigen Teammitglieder, die mich anfangs gemobbt hatten, waren am Ende diejenigen, die meinen Abgang am meisten bedauerten.

Leistungsträger sind wettbewerbsorientiert, aber sie respektieren und schätzen auch diejenigen, die starke Führung zeigen und Dinge vorantreiben.

Während der zwei Jahre arbeitete ich kontinuierlich daran, die Vision und Mission des Teams, seine Position innerhalb der Unternehmensgrenzen und die Projekte zu verfeinern.
Eine der wichtigsten Voraussetzungen für den Erfolg war die großartige Zusammenarbeit mit dem CTO. Auch die Unterstützung durch das Management für eine so experimentelle Reise war keine Selbstverständlichkeit.

Für mich ist es zentral, das Management immer im Boot zu haben und mit sinnvoller Frequenz über den Status der Projekte zu informieren.

Kontrolle vs. Mikromanagement

Die Projektleitung braucht ein Rahmenwerk der Kontrolle, aber kein Mikromanagement.

Wenn Sie als Projektleiter in alle Details involviert sein wollen, reicht Ihr Tag nicht aus. Mikromanagement ist keine Option. Sie müssen den Teammitgliedern vertrauen und ihnen Raum lassen, Verantwortung zu übernehmen. Besonders zu Beginn der Zusammenarbeit ist dies eine riskante Herausforderung. Als Projektleiter müssen Sie herausfinden, wer für bestimmte Themen die Führung übernehmen kann, und dann Vertrauen schenken. Gleichzeitig müssen Sie eine Möglichkeit finden, in agiler Weise Kontrollen zu machen und gegebenenfalls Korrekturen vorzunehmen.

Wenn Sie versuchen, alles ständig zu kontrollieren, nehmen Sie anderen die Möglichkeit, Verantwortung zu übernehmen.

Mit zunehmender Komplexität eines Projekts führt dies in eine destruktive Spirale, bei der jedes Thema letztlich auf Ihren Tisch zurückfällt und möglicherweise das gesamte Vorhaben zum Scheitern bringt.

Es gab einen Moment, während wir uns auf das Backend konzentrierten, in dem das Frontend zum Chaos wurde, weil jeder Entwickler seinen eigenen Programmieransatz verfolgte.

Dies führte zu einer hitzigen Diskussion und ich musste klarstellen, was ich von jedem Teammitglied erwartete. Das Refactoring dauerte fast einen Monat und verärgerte einige Entwickler.

Rückblickend war das Refactoring definitiv die richtige Entscheidung, da wir dadurch einen einheitlichen Programmierstil im Team etablieren konnten.

Für mich ist es sehr wichtig, die Persönlichkeit jedes Teammitglieds zu verstehen, was sie gerne tun, was sie ungern tun und worin sie gut sind.

Die Philosophie von Scrum sieht vor, dass jedes Teammitglied Aufgaben selbstständig übernimmt, doch dieser Ansatz überzeugt mich nicht. Als Projektleiter habe ich eine klare Vision, wie ich die Mitglieder des Teams individuell fördern, unterstützen und weiterentwickeln möchte. Mein Fokus liegt dabei auf der persönlichen Weiterentwicklung des Entwicklers genauso wie auf dem Fokus, dass diese zu mehr Effizienz in der zukünftigen Umsetzung führen.

Ich messe meinen Erfolg als Führungskraft daran, wie sehr ich die Karriere und persönliche Entwicklung jedes Teammitglieds fördern konnte, neben den geschäftlichen Erfolgen.

Als Führungskraft bleiben viele Themen und viel Arbeit bei Ihnen.

Sie müssen Prioritäten setzen und Ihre Zeit und Energie weise verwalten!

Diese Geschichte enthält viele Erkenntnisse über meinen persönlichen Führungsstil, konzentriert sich jedoch stark auf die Aspekte der Teamführung.

Es gibt viele weitere Themen im Bereich Führung zu behandeln. Bleiben Sie dran!

Wie führen Sie? Was sind Ihre Geschichten?