Führen ohne Macht

Influence has always been, and will always be, the currency of leadership.

Mit diesen Worten trifft Clay Scroggins den Kern einer Herausforderung, der sich Entwickler täglich stellen: Wie können sie in einem komplexen Umfeld Einfluss nehmen und Veränderungen bewirken, auch wenn sie keine formale Führungsposition innehaben?

Die Realität in Softwareunternehmen ist oft paradox: Entwickler verfügen über tiefgreifendes technisches Wissen und sehen häufig Verbesserungspotenziale – sowohl in der Codebasis als auch in Prozessen und Strukturen. Dennoch fühlen sie sich oft machtlos, diese Veränderungen auch tatsächlich anzustoßen. “Das ist nun mal die Vorgabe von oben” oder “Da können wir nichts machen” sind Sätze, die in Entwicklungsteams häufig zu hören sind.

Doch diese vermeintliche Machtlosigkeit ist eine Illusion. Wie Clay Scroggins in “How to Lead When You’re Not in Charge” eindrucksvoll darlegt, liegt der Schlüssel zu echter Führung nicht in der formalen Autorität, sondern in der Fähigkeit, Einfluss auszuüben. Eine Erkenntnis, die besonders für Entwickler von fundamentaler Bedeutung ist.

1. Die Identitätsfrage: Wer bin ich als Führungskraft?

Bevor wir über konkrete Führungstechniken sprechen können, müssen wir uns einer fundamentalen Frage stellen: Wie sehen wir uns selbst? Scroggins argumentiert überzeugend, dass jede Diskrepanz zwischen der Autorität, die wir haben, und der Führung, die wir ausüben, auf eine Identitätskrise zurückzuführen ist.

In der Softwareentwicklung manifestiert sich diese Identitätskrise besonders deutlich. Ein typisches Beispiel: Ein Developer identifiziert eine technische Schuld, die dringend adressiert werden muss – veraltete Bibliotheken, inkonsistente Architekturen, fehlende Tests. Doch statt aktiv eine Lösung voranzutreiben, wartet er auf “grünes Licht” von oben. Seine Identität ist die eines Ausführenden, nicht die eines Gestalters.

Diese Haltung ist symptomatisch für ein tieferliegendes Problem: Die Definition der eigenen Identität erfolgt oft über die formale Position statt über den potenziellen Einfluss. Scroggins unterscheidet hier verschiedene Komponenten der Identität:

1.1 Das Selbst in der Zeit

Vergangene Erfahrungen prägen, wie sich Entwickler heute sehen. Sie tragen oft eine Geschichte von technischer Expertise, aber vielleicht auch von überstimmten Vorschlägen oder ignorierten Bedenken mit sich. Diese Erfahrungen können entweder lähmen oder stärken – je nachdem, wie sie interpretiert werden.

1.2 Unser Umfeld

Die Menschen im Arbeitsumfeld beeinflussen maßgeblich das Selbstbild. In einem Team, das Initiative und Querdenken fördert, entwickelt sich eher eine Führungsidentität als in einem, das strikten Hierarchien folgt.

1.3 Unsere Persönlichkeit

Technische Expertise und Führungsfähigkeit sind keine Gegensätze. Viele Entwickler sehen sich primär als “Technical Contributor”, dabei können gerade analytische Fähigkeiten und systematisches Denken wertvolle Führungsqualitäten sein.

1.4 Unser Zweck

Die Frage nach dem “Warum” ist entscheidend. Sehen Entwickler ihre Aufgabe nur in der Implementierung von Features, oder verstehen sie sich als Gestalter, die durch Technologie echten Mehrwert schaffen?

1.5 Unsere Prioritäten

Werte und Überzeugungen formen, wie Führung verstanden und ausgeübt wird. Ein Entwickler, der Codequalität und nachhaltige Architektur als höchste Priorität sieht, wird anders führen als jemand, der schnelle Releases priorisiert.

Die Erkenntnis, dass diese Identitätskomponenten formbar sind, ist befreiend. Niemand ist auf eine passive Rolle festgelegt, sondern kann aktiv eine Führungsidentität entwickeln – unabhängig von der formalen Position.

2. Von Kibosh zu Kabash: Die Transformation der Ambition

Ein besonders faszinierendes Konzept in Scroggins’ Buch ist die Unterscheidung zwischen “Kibosh” und “Kabash”. Während Kibosh für das Ersticken von Initiativen steht (Etwas ein Ende setzen oder es endgültig beseitigen), beschreibt Kabash (Etwas bändigen, kultivieren und so organisieren, dass es sich entfaltet, entwickelt und zur vollen Blüte kommt) die positive Kraft der Gestaltung und Kultivierung.

Ein Beispiel aus der Praxis verdeutlicht diese Dynamik: In einem Entwicklungsteam schlug ein Junior Developer vor, die bestehenden Legacy-Monolithen schrittweise in Microservices zu überführen. Die erste Reaktion des Teams war klassisches Kibosh-Denken: “Das haben wir schon immer so gemacht”, “Das ist zu riskant”, “Dafür haben wir keine Zeit”. Doch statt sich entmutigen zu lassen, wandelte der Entwickler seine Ambition in Kabash um: Er erstellte einen Proof of Concept für einen kleinen, isolierten Service, dokumentierte die Vorteile und Risiken sorgfältig und präsentierte seine Erkenntnisse in einem Tech Talk. Sein konstruktiver Ansatz führte schließlich dazu, dass das Team die Transformation schrittweise umsetzte.

3. Die vier Kernverhaltensweisen erfolgreicher Führung

Scroggins identifiziert vier fundamentale Verhaltensweisen, die erfolgreiche Führung ohne formale Autorität ermöglichen. Diese Prinzipien sind besonders relevant für Entwickler, da sie direkt auf den Arbeitsalltag übertragbar sind.

3.1 Lead Yourself: Die Kunst der Selbstführung

“Your boss is not in charge of you. You are in charge of you.” Diese provokante These von Scroggins trifft einen wunden Punkt in vielen Entwicklerteams. Zu oft schieben Entwickler die Verantwortung für ihre Entwicklung auf andere – den Tech Lead, den Scrum Master, das Management.

Ein typisches Beispiel illustriert diese Situation: Ein Entwickler beklagt sich regelmäßig über mangelnde Weiterbildungsmöglichkeiten im Unternehmen. Als er gefragt wird, welche Technologien er denn gerne lernen würde, hat er keine konkrete Antwort. Er wartet darauf, dass jemand ihm seinen Entwicklungspfad vorzeichnet.

Echte Selbstführung bedeutet:

1. Ehrliche Standortbestimmung: Wo stehe ich technisch und persönlich? Ein effektiver Ansatz ist das Führen eines “Skills Journal”, in dem regelmäßig dokumentiert wird, welche Technologien beherrscht werden, wo Lücken bestehen und welche Trends zu beobachten sind.

2. Klare Vision entwickeln: Wohin will ich mich entwickeln? Ein Senior Developer könnte beispielsweise die Vision entwickeln, die Testkultur zu verbessern. Dafür definiert er konkrete Meilensteine: Einführung von Unit Tests, Aufbau einer CI/CD-Pipeline, Etablierung von Code Reviews.

3. Konsequente Umsetzung: Welche konkreten Schritte gehe ich? Ein gutes Beispiel ist eine Entwicklerin, die ihre Präsentationsfähigkeiten verbessern möchte. Sie beginnt mit Lightning Talks im Team, übernimmt dann Sprint Reviews und hält schließlich regelmäßig Vorträge auf Konferenzen.

3.2 Choose Positivity: Die Macht der konstruktiven Haltung

Positivität wird oft missverstanden als naive Optimismus. Scroggins beschreibt sie jedoch als bewusste Entscheidung, Probleme als Chancen zu sehen. In der Softwareentwicklung ist diese Haltung besonders wertvoll, da Teams ständig mit Herausforderungen konfrontiert sind.

Ein eindrückliches Beispiel zeigt sich während einer besonders schwierigen Produkteinführung: Ein System zeigt unter Last unerwartete Fehler. Während ein Teil des Teams in Frustration und Schuldzuweisungen verfällt, nimmt ein Entwickler eine andere Haltung ein. Er sagt: “Das ist eine einmalige Gelegenheit, unser Monitoring zu verbessern und unsere Architektur stressresistenter zu machen.” Diese Perspektive verändert die gesamte Teamdynamik. Statt eines Problems hat das Team plötzlich eine spannende technische Challenge vor sich.

Positivität in der Praxis bedeutet:

1. Probleme als Lernchancen sehen Bei massiven Performance-Problemen in einer Datenbank kann die Situation genutzt werden, um sich intensiv mit Query-Optimierung und Caching-Strategien auseinanderzusetzen. Das dabei gewonnene Wissen ist langfristig wertvoll.

2. Fokus auf Lösungen statt Schuldzuweisungen Nach einem kritischen Produktionsfehler können “Blameless Postmortems” eingeführt werden. Der Fokus liegt nicht darauf, wer den Fehler gemacht hat, sondern wie Systeme und Prozesse verbessert werden können.

3. Erfolge aktiv wahrnehmen und feiern Ein effektiver Ansatz ist die Einführung einer “Win Wall” im Team, wo nicht nur große Meilensteine, sondern auch kleine Fortschritte dokumentiert werden: der erste erfolgreiche Deployment einer neuen Komponente, positive Kundenfeedbacks, gelöste technische Herausforderungen.

3.3 Think Critically: Die Balance zwischen Akzeptanz und Hinterfragen

Kritisches Denken ist eine Kernkompetenz in der Softwareentwicklung. Doch Scroggins erweitert dieses Konzept über das rein Technische hinaus. Es geht darum, das große Ganze zu verstehen und konstruktiv zu hinterfragen.

Ein Beispiel verdeutlicht die Bedeutung dieser Balance: Ein Team erhält die Anforderung, ein bestehendes Feature komplett neu zu implementieren. Die übliche Reaktion wäre, die Spezifikation einfach umzusetzen. Stattdessen beginnt das Team, kritische Fragen zu stellen:

• Warum genau muss das Feature neu implementiert werden?
• Welche Probleme sollen damit gelöst werden?
• Gibt es vielleicht elegantere Lösungen für diese Probleme?

Diese Fragen führen zu wichtigen Erkenntnissen. Das eigentliche Problem liegt nicht im Feature selbst, sondern in der Art, wie es genutzt wird. Durch einige gezielte Anpassungen und bessere Dokumentation kann der Bedarf mit einem Bruchteil des ursprünglich geplanten Aufwands erfüllt werden.

Kritisches Denken in der Praxis:

1. Systematische Problemanalyse Bei Performance-Problemen sollten nicht einfach blind Optimierungen durchgeführt werden. Stattdessen können Metriken analysiert, Hypothesen erstellt und diese systematisch validiert werden.

2. Annahmen hinterfragen “Das haben wir schon immer so gemacht” ist keine ausreichende Begründung. Eine gute Praxis ist es, die Gründe für technische Entscheidungen aktiv in Architecture Decision Records (ADRs) zu dokumentieren.

3. Verschiedene Perspektiven einholen Bei wichtigen Architekturentscheidungen können bewusst Kollegen aus anderen Teams eingeladen werden, um Annahmen und Lösungsansätze zu challengen.

3.4 Reject Passivity: Von der Reaktion zur Aktion

Die vierte Kernverhaltensweise nach Scroggins ist vielleicht die wichtigste für Entwickler: die Ablehnung von Passivität. Zu oft verstecken sich Entwickler hinter der Ausrede “Das ist nicht meine Entscheidung” oder “Dafür bin ich nicht zuständig”. Doch echte Führung bedeutet, Initiative zu ergreifen – auch ohne formale Autorität.

Ein Beispiel verdeutlicht die Kraft dieser Haltung: In einem Projekt leidet die Codequalität unter dem ständigen Zeitdruck. Die übliche Reaktion wäre, dies zu akzeptieren und weiterzumachen wie bisher. Stattdessen ergreift ein Entwickler die Initiative. Er analysiert die häufigsten Qualitätsprobleme, entwickelt einen Vorschlag für automatisierte Code-Analysen und präsentiert konkrete Beispiele, wie diese Tools Zeit sparen würden. Sein proaktiver Ansatz überzeugt nicht nur das Team, sondern auch das Management. Die Tools werden fester Bestandteil der Entwicklungspipeline.

Die Ablehnung von Passivität zeigt sich in verschiedenen Aspekten:

1. Proaktive Problemlösung Ein gutes Beispiel: Ein Junior Developer bemerkt, dass neue Teammitglieder oft Wochen brauchen, um sich in die Entwicklungsumgebung einzuarbeiten. Anstatt dies als gegeben hinzunehmen, erstellt er eine detaillierte Onboarding-Dokumentation und entwickelt Scripts zur automatischen Einrichtung der Entwicklungsumgebung. Seine Initiative reduziert die Einarbeitungszeit drastisch.

2. Verantwortung übernehmen Ein Beispiel zeigt sich bei der Einführung von DevOps-Praktiken: Niemand hat den offiziellen Auftrag dazu, aber einige Entwickler erkennen die Notwendigkeit. Sie beginnen, sich in Monitoring-Tools einzuarbeiten, automatisierte Deployments aufzusetzen und andere im Team zu schulen. DevOps wird zu einem integralen Bestandteil der Arbeitsweise.

3. Konstruktive Vorschläge statt Beschwerden Ein klassisches Beispiel: Die Daily Standups werden zunehmend ineffektiv. Statt nur darüber zu klagen, entwickelt eine Entwicklerin ein neues Format: Sie führt eine “Blocker-First”-Politik ein, bei der zuerst alle Hindernisse besprochen werden. Zusätzlich etabliert sie wöchentliche “Deep Dive”-Sessions für technische Diskussionen, die im Daily zu viel Zeit kosten würden. Diese Änderungen machen die Meetings deutlich produktiver.

4. Die praktische Umsetzung im Entwickleralltag

Die Theorie klingt überzeugend, aber wie lassen sich diese Prinzipien in der Praxis umsetzen? Basierend auf Scroggins’ Ansatz haben sich folgende Strategien bewährt:

4.1 Kleine Schritte, große Wirkung

Der Schlüssel liegt oft in kleinen, aber konsequenten Schritten. Ein Beispiel: Ein Entwickler beginnt damit, nach jedem Pull Request kurze Notizen zu den wichtigsten Architekturentscheidungen zu machen. Was als persönliche Dokumentation beginnt, entwickelt sich zu einem wertvollen Wissensspeicher für das gesamte Team. Daraus entstehen regelmäßige Architektur-Reviews, bei denen diese Dokumentation als Basis dient.

4.2 Beziehungen aufbauen

Führung ohne Autorität basiert wesentlich auf Vertrauen und Beziehungen. Ein effektiver Ansatz ist das Konzept des “Tech Coffee”: Entwickler aus verschiedenen Teams treffen sich regelmäßig zum informellen Austausch. Was als lockere Kaffeepause beginnt, wird zu einem wichtigen Forum für technische Diskussionen, Problemlösungen und teamübergreifende Zusammenarbeit.

4.3 Expertise teilen

Wissen ist eine Form von Einfluss. Ein praktisches Beispiel ist die Einführung einer wöchentlichen “Learning Hour”. In diesen Sessions teilt jeweils ein Teammitglied sein Wissen zu einem spezifischen Thema – von Designpatterns bis zu neuen Technologien. Der Effekt ist bemerkenswert: Nicht nur steigt das technische Niveau des Teams, auch die Kommunikation und das gegenseitige Verständnis verbessern sich deutlich.

4.4 Feedback kultivieren

Konstruktives Feedback ist ein wichtiges Instrument der Führung. Ein strukturierter Ansatz könnte so aussehen:

• Regelmäßige Code Reviews: Nicht als Kontrolle, sondern als Gelegenheit zum Lernen und zur Verbesserung
• Technische Retrospektiven: Monatliche Meetings, in denen technische Entscheidungen reflektiert werden
• Peer Learning Sessions: Entwickler arbeiten paarweise an Problemen und geben sich gegenseitig Feedback

Ein konkretes Beispiel: Nach einem schwierigen Projekt führt ein Team eine “Technical Debt Review” durch. Jeder Entwickler präsentiert die in seinem Bereich identifizierten technischen Schulden und schlägt Verbesserungen vor. Aus dieser Initiative entsteht ein kontinuierlicher Verbesserungsprozess, der fest in der Entwicklungskultur verankert wird.

5. Die Realität: Zwischen Theorie und Praxis

Die Prinzipien von Scroggins sind überzeugend, doch ihre Umsetzung in der Realität stellt Entwickler oft vor Herausforderungen. Der Entwicklungsalltag zeigt regelmäßig Situationen, die die Spannung zwischen Führungsambitionen und organisatorischen Realitäten deutlich machen.

5.1 Die Herausforderung der etablierten Strukturen

Ein besonders prägnantes Beispiel zeigt sich in einem größeren Projekt: Ein Entwicklungsteam erkennt, dass ihre Microservice-Architektur zu feinkörnig geworden ist und die Komplexität unnötig erhöht. Die Kommunikation zwischen den Services ist schwer zu debuggen, und die Deployments werden zunehmend riskanter.

Das Team entwickelt einen detaillierten Vorschlag zur Konsolidierung einiger Services. Sie sammeln Metriken, dokumentieren Probleme und erstellen einen schrittweisen Migrationsplan. Doch dann prallen sie auf die organisatorische Realität: Die Services sind verschiedenen Teams zugeordnet, jedes Team hat seine eigenen Prioritäten, und die Budgetierung ist auf die bestehende Struktur ausgerichtet.

Die erste Reaktion ist Frustration. Doch dann erinnert sich das Team an Scroggins’ Prinzipien:

1. Lead Yourself: Statt in Frust zu verfallen, konzentrieren sie sich darauf, was sie beeinflussen können.
2. Choose Positivity: Sie sehen die Situation als Chance, teamübergreifende Zusammenarbeit zu verbessern.
3. Think Critically: Sie analysieren die organisatorischen Hindernisse genauer.
4. Reject Passivity: Anstatt aufzugeben, entwickeln sie eine neue Strategie.

Sie beginnen, kleine Workshops zu organisieren, in denen sie die Probleme und möglichen Lösungen mit anderen Teams diskutieren. Statt einer großen Reorganisation schlagen sie vor, mit zwei Services zu beginnen, deren Teams am offensten für Veränderungen sind. Der Erfolg dieser ersten Konsolidierung überzeugt schließlich auch andere Teams.

5.2 Die Kunst des indirekten Einflusses

Eine wichtige Erkenntnis aus der Praxis ist, dass Führung ohne Autorität oft indirekt funktioniert. Ein Beispiel aus dem Qualitätsmanagement verdeutlicht dies: Ein Team möchte die Testabdeckung verbessern, stößt aber auf Widerstand, weil dies zunächst die Entwicklungsgeschwindigkeit reduzieren würde.

Statt dies als Top-down-Entscheidung durchzusetzen (was ohnehin nicht möglich wäre), wählen sie einen subtileren Ansatz:

1. Sie beginnen, in Code Reviews gezielt nach Tests zu fragen – nicht als Kritik, sondern als konstruktive Diskussion.
2. In ihren eigenen Pull Requests demonstrieren sie, wie gut testbarer Code aussieht.
3. Sie dokumentieren Fälle, wo Tests vor Regressionen bewahrt haben.
4. Sie organisieren informelle “Testing Dojos”, wo Teams spielerisch Teststrategien entwickeln können.

Nach einigen Monaten hat sich die Testkultur spürbar verbessert – nicht durch Anordnung, sondern durch kontinuierliche, positive Beeinflussung.

5.3 Die Bedeutung der Authentizität

Eine besonders wichtige Lektion aus Scroggins’ Buch, die sich in der Praxis bestätigt, ist die Bedeutung der Authentizität. Führung ohne Autorität funktioniert nur, wenn sie authentisch ist. Ein Beispiel illustriert dies eindrücklich:

Ein Entwickler versucht, mehr Führungsverantwortung zu übernehmen, indem er den “typischen” Führungsstil imitiert – direktiv, selbstbewusst, immer eine Antwort parat. Das Team reagiert skeptisch, weil dieser Stil nicht zu seiner sonstigen Persönlichkeit passt. Als er stattdessen beginnt, seinen eigenen, eher analytischen und unterstützenden Führungsstil zu entwickeln, gewinnt er deutlich mehr Einfluss.

5.4 Der Weg nach vorn

Die Umsetzung von Scroggins’ Prinzipien ist ein kontinuierlicher Prozess, kein einmaliges Projekt. Die Erfahrung zeigt, dass echte Führung ohne Autorität bedeutet:

1. Geduld zu haben: Veränderungen brauchen Zeit, besonders wenn sie ohne formale Autorität erreicht werden müssen.
2. Flexibel zu bleiben: Manchmal führt ein Umweg schneller zum Ziel als der direkte Weg.
3. Beziehungen zu pflegen: Informelle Netzwerke sind oft wichtiger als formale Strukturen.
4. Authentisch zu bleiben: Nur wer seinem eigenen Führungsstil treu bleibt, kann langfristig Einfluss ausüben.

6. Fazit: Die stille Revolution

Scroggins’ Ansatz zur Führung ohne Autorität ist mehr als ein theoretisches Konzept – er ist ein praktischer Weg, wie Entwickler echte Veränderungen bewirken können. In einer Zeit, in der technische Expertise allein nicht mehr ausreicht, bietet er einen Kompass für effektive Einflussnahme.

Die Herausforderungen sind real, aber die Möglichkeiten sind es auch. Durch bewusstes Self-Leadership, positive Haltung, kritisches Denken und aktives Handeln können Entwickler auch ohne formale Autorität bedeutende Veränderungen anstoßen. Der Schlüssel liegt darin, diese Prinzipien nicht als Techniken, sondern als Haltung zu verstehen und sie authentisch in den Entwickleralltag zu integrieren.

Wie Scroggins es ausdrückt: “Influence has always been, and will always be, the currency of leadership.” In der Softwareentwicklung war diese Erkenntnis nie wichtiger als heute.