- Große, auf Spezialisten ausgerichtete Teams leiden unter internen Abhängigkeiten, Übermittlungsfehlern, Engpässen und verteilter Verantwortung, was zu einem starken Rückgang von Produktivität und Effizienz der Zusammenarbeit führt
- In täglichen Stand-up-Meetings wird der Großteil der Inhalte unnötig oder langweilig; wachsender Teamumfang und stärkere Spezialisierung führen zu Kommunikationsabbrüchen und Desinteresse
- Es gab mehrere Experimente wie die Trennung nach Technologien (Frontend/Backend), temporäre Feature-Teams und den Einsatz externer Berater, doch letztlich erwies sich der Wechsel zu generalistischen Rollen als am wirksamsten
- Gemeinsame Zusammenarbeit wie Mob Programming fördert Wissensaustausch, Eigenverantwortung, Verantwortungsbewusstsein und Motivation und ist für ergebnisorientierte Zusammenarbeit und Wachstum vorteilhafter als das Festhalten an einzelnen Fachgebieten
- Allerdings gibt es auch Nebenwirkungen der Generalisierung (geringere fachliche Tiefe, Burnout-Risiko), weshalb kontinuierliche Experimente und kulturelle Verbesserungen unerlässlich sind
Probleme, wenn ein Team zu groß ist
- Probleme, die in einem großen Team mit 14 Personen begannen: In Stand-ups war der Großteil der Gespräche unnötig, zudem wurden Aufgaben bei der Übergabe häufig übersehen und informelle Arbeit kam oft vor
- Auch der Wechsel zu asynchronen Stand-ups (Slack usw.) ließ wesentliche Gespräche und Gelegenheiten zur Zusammenarbeit verschwinden und verwandelte das Format in bloße Berichte
Verschiedene Experimente bei Aufteilung und Betrieb
- Trennung nach Technologien (Task Force): Aufteilung in Frontend und Backend, doch sofort traten gegenseitige Abhängigkeiten auf, und die zusätzliche Teilnahme an Stand-ups kostete mehr Zeit
- Temporäre Feature-Teams: Mitarbeitende wurden je nach Umsetzung bestimmter Funktionen vorübergehend umverteilt, was Probleme bei Wartung und Ressourcenmanagement verursachte
- Einsatz externer Berater: Trotz bereits großer Teamgröße ineffizient, zudem gab es Druck des oberen Managements zur Nutzung der Ressourcen
Die letztlich wirksame Lösung
- Einführung eines Generalisten-Modells statt Spezialisten
- Statt getrennter Rollen wie Frontend, Backend, QA oder DevOps wurde der gesamte Skillset rund um ein gemeinsames Ziel bzw. Produkt aufgeteilt
- Dadurch wurden Wissensaustausch, weniger verteilte Verantwortung, der Abbau von Engpässen sowie schnellere Lieferung und höhere Qualität erreicht
- Gruppenbasierte Zusammenarbeit wie Mob Programming stärkte Kommunikation, Autonomie und Ownership
Warum Generalisten effektiv waren
- Gemeinsamer Kontext und gemeinsames Ziel: Selbst in neuen Bereichen wurde die Lernkurve durch dasselbe Produkt bzw. Ziel abgeflacht
- Begrenzter Bedarf: Es reichte aus, bestimmte Tools (CI/CD usw.) zu beherrschen; wichtiger als tiefe Spezialisierung waren Produktivität und Wartbarkeit
- Erfüllung aller drei Motivationsfaktoren (Autonomie, Meisterschaft, Sinn/Zweck), was Ownership und Wachstum im Team unterstützte
- Egalitäre Kultur: gleicher Zugang, selbstbestimmter Wissenserwerb, verteilte Befugnisse und Verantwortung, gemeinsames Lernen
- Die drei Elemente der Verantwortung (Wissen, Befugnis, Verantwortung) waren klar, wodurch auf Ownership basierende schnelle und qualitativ hochwertige Ergebnisse möglich wurden
Nebenwirkungen und Grenzen
- Abwanderung von Experten: Generalisierung passt nicht zu allen; bei bestimmten Mitarbeitenden kam es zu Burnout und Überlastung der Ressourcen
- Mangel an fachlicher Tiefe: Wer mit vielen Stacks nur oberflächlich arbeitet, kann tiefe Expertise in einem einzelnen Bereich schwerer aufbauen
Fazit und Erkenntnisse
- Es gibt keine einheitliche Lösung; wichtiger ist eine Kultur des Experimentierens und Verbesserns
- Nachteile des Spezialisten-Modells wie Engpässe, Kommunikationsabbrüche, Fake Work und Kontextverlust lassen sich durch Generalisten und kollektive Zusammenarbeit abmildern
- Letztlich kann sich das optimale Modell je nach Ziel, Personal, Budget und Produkteigenschaften unterscheiden
- Entscheidend ist eine Kultur offener Experimente, von Feedback und kontinuierlicher Verbesserung
4 Kommentare
Ich bin zwar Generalist, aber in der Praxis habe ich Folgendes erlebt.
Nützlich sind Generalisten, aber echte „Wertschätzung“ erfahren letztlich Spezialisten.
Selbst wenn man von derselben Universität kommt und die gleichen Noten hat, ist es am Ende Realität, dass Spezialisten zwei- bis dreimal so hoch bezahlt werden.
Ich denke ähnlich.
Aber meiner Meinung nach sind Spezialisten im Softwarebereich – außer vielleicht in der amerikanischen Deeptech-Szene – nicht wirklich so speziell.
Könnten Sie vielleicht ein Beispiel geben? Mich würde interessieren, wie „special“ jemand in der Praxis sein muss, um als Spezialist bezeichnet zu werden ...
Nach HR-Maßstäben scheint man in Großunternehmen oder im gehobenen Mittelstand etwa drei Jahre Berufserfahrung zu verlangen, und mein Maßstab für einen „Spezialisten“ ist aus Backend-Sicht, ob jemand unter Nutzung von LLMs eine Struktur entwerfen kann, die für alle leicht nutzbar ist und zugleich hohe Verfügbarkeit berücksichtigt.
Ich bin zum Beispiel ein Generalist, kann aber für jeden beliebigen inländischen Service mit mehr als 100 Millionen Nutzern den Traffic so einfach entwerfen, dass selbst ein Grundschüler es verstehen würde.
Aber weil ich eben auch Generalist bin, werde ich bei Bewerbungen bei Großunternehmen direkt aussortiert, haha