Kernbotschaften
- Überlastete Tech-Leads, Teamleads, Projektleiter:innen und Scrum Master sind meist Symptome systemischer Probleme: fehlende Rollenklarheit, Entscheidungsarchitektur und Entscheidungsprozesse.
- Führungskräfte im Mittelstand sollten gezielt schauen, wo sie Impact von Lead-Rollen erwarten – und ob dafür Strukturen, Umfeld und Entscheidungsprozesse (z.B. RFC) überhaupt passend sind.
- RFCs sind ein schlanker Weg, Entscheidungen transparent, asynchron und gemeinsam zu treffen – Lead-Rollen werden vom Einzel-Held zum Facilitator eines Systems.
- Das 2-Cycles-Modell bietet einen systemischen Layer: Es verknüpft Umfeld, Strukturen, Handlungen, Weltsicht und Motivation und hilft, jenseits von „Mindset“ an echten Hebeln zu arbeiten.
Wenn Team- und andere Leads überlastet sind: Ein Organisationsproblem – kein Persönlichkeitsproblem
In vielen Produkt- und Medienunternehmen sehen wir dasselbe Muster: Tech-Leads, Teamleads, Projektleiter:innen und Scrum Master sollen „den Laden zusammenhalten“. Sie moderieren Konflikte, vertreten Entscheidungen nach oben und unten, sind fachliche Ansprechpartner:innen – und sollen gleichzeitig nah genug am Team bleiben, um operative Probleme zu lösen.
Die unbequeme Wahrheit:Wenn diese Rollen überlastet sind, liegt das selten an den Menschen – sondern fast immer an unklaren Rollen, Entscheidungen und Strukturen.
Die Tech-Lead-Rolle ist ein guter Stellvertreter-Fall, um dieses Muster sichtbar zu machen. Wer hier genauer hinschaut, erkennt schnell: Das Problem ist systemisch – und betrifft zahlreiche Lead-Rollen rund um Produktentwicklung, Projekte und IT.
1. Falle: „Der Rollenzuschnitt ist vage“
Meine Beobachtung ist:Tech-Leads, Teamleads, Projektleiter:innen und Scrum Master werden oft mit einem impliziten „Führungs- und Fach-Superpaket“ ausgestattet.
Auf dem Papier steht dann etwas wie „Führung eines Teams“ oder „Verantwortung für das Projekt“. In der Praxis kommen selbstverständlich weitere Erwartungen dazu:
- fachliches Coaching der Kolleg:innen
- Aufgaben eines Software-Architekten oder Senior-Expert:in
- möglichst hohe eigene operative Anteile (Programmierung, Konzeptarbeit, Moderation)
- Ansprechperson für eine Vielzahl von Stakeholdern
- Sparringspartner für Produktmanagement / Business
- frühe Einbindung in Discovery-Phasen und strategische Diskussionen
Das funktioniert eine Weile „irgendwie“, vor allem mit hoch engagierten Menschen. (Nicht selten kämpfen die dann schon bald mit einhergehenden Erschöpfungszuständen was wiederum zu Überforderungssymptomen führen kann.)
Doch in wachsenden Organisationen sind Entscheidungswege und Verantwortlichkeiten häufig volatil – sie verschieben sich, ohne dass jemand systematisch nachzieht.
Wenn Führung diese Verdichtung von Aufgaben und Verantwortungen nicht bewusst beobachtet und adressiert, ist Überlastung keine Überraschung, sondern die logische Folge.
- People-Lead / Teamlead: 1:1s, Gehalt, Karriere, Kultur, Admin.
- Fach-Lead (z.B. Tech-Lead): Architektur, Methoden, Standards, fachliches Coaching – mit realistischer Kapazität (z.B. 20–30% operative Arbeit statt „voll mitentwickeln“).
2. Falle: „Mehr Leistung statt bessere Entscheidungen“
- Unklare Entscheidungsarchitektur
Niemand kann genau sagen, wer welche Entscheidungen trifft – Tech-Lead, Product, Management, Team? Also „hängen“ Lead-Rollen in jeder Entscheidungsschleife. Folgen: Mehr Abstimmungsbedarf, mehr Meetings, mehr Koordination – weniger Wertschöpfung. - Zu viele parallele Initiativen (WiP)
Teams arbeiten an zu vielen Themen gleichzeitig. „Nein“ wird selten aktiv vertreten. Lead-Rollen jonglieren ständig Kontextwechsel und Prioritätskonflikte, statt Probleme nachhaltig zu lösen.
Die relevante Frage lautet also: Was sind die relevanten Entscheidungen die im Team, in der Organisation von Team/Tech-Leads etc. getroffen werden sollen um dabei zu helfen in der Organisation den Wertbeitrag zu steigern? Oder einfacher: Notwendige/wertvolle Entscheidungen vs. wenig getroffene Entscheidungen weil „unsicher“ und „unklar“.
3. Falle: „Formale Prozesse machen uns langsam“
- Entscheidungen sind schlecht dokumentiert.
- Wissen hängt an einzelnen Personen (oft an Lead-Rollen).
- Neue Kolleg:innen verstehen Entscheidungslogiken nicht, müssen alles individuell nachfragen.
Ohne leichtgewichtige Struktur werden Lead-Rollen zu lebenden Wissens- und Entscheidungsarchiven – unverzichtbar und gleichzeitig permanent überlastet.
Was RFC sind – und warum sie helfen
Typische Formen:
- Decision RFC: Verbindliche Entscheidung mit klarer Owner-Rolle (z.B. Architekturentscheidungen, Organisationsänderungen).
- Exploration RFC: Hypothesen, Optionen und Risiken zur Exploration, bevor man sich festlegt.
- Standard RFC: Definitionen von Standards und Prozessen (Definition of Done, Branch-Strategien, Oncall-Regeln, Meeting-Formate).
Der Effekt: Entscheidungen wandern aus Köpfen und Einzelmeetings in einen gemeinsamen Prozess. Lead-Rollen (Tech-Lead, Teamlead, Projektleitung, Scrum Master) moderieren diesen Prozess, statt alle Entscheidungen allein tragen zu müssen.
Beispiel: Ein RFC-Prozess in fünf Schritten („Zu viele Meetings“)
- Trigger: „Problem entsteht“ Mehrere Leads melden: „Wir hängen nur noch in Meetings, kommen kaum zum Arbeiten.“ Eine Person übernimmt die Owner-Rolle.
- RFC schreiben: In Confluence, Notion, Mail oder einem Teams/Slack-Kanal werden Problem, Kontext, Optionen und ein Vorschlag beschrieben – als Entscheidungsgrundlage –> Oder initial in einer Tech-Lead Runde adressieren.
- Feedback asynchron einholen: Relevante Rollen (Leads, Product, Führung) kommentieren direkt am RFC. Kein Pflicht-Meeting für jede Kleinigkeit.
- Klärungsmeeting – nur wenn nötig: Wenn Konflikte offen sind oder Klärungsbedarf besteht, gibt es ein fokussiertes Meeting auf Basis des RFC, nicht von Null.
- Entscheidung & Follow-up : Der RFC bekommt einen Status („accepted“, „experiment“, „rejected“), die Entscheidung ist dokumentiert, Umsetzungsschritte sind klar.
Das Webinar für junge Führungskräfte
Systemischer Layer mit dem 2-Cycles-Modell
- Umfeld : Wachstum, Fachkräftemangel, hohe Erwartung an Geschwindigkeit, vielleicht Druck von Investor:innen oder Geschäftsführung.
- Strukturen: Alles wird in eine Lead-Rolle gepackt, Entscheidungsarchitektur ist unklar, es gibt viele Meetings ohne klare Funktion, RFC-Prozesse fehlen.
- Handlungen : Leads springen von Meeting zu Meeting, moderieren Ad-hoc-Entscheidungen, arbeiten ständig im „Feuerwehrmodus“.
- Weltsicht: „Leads sind nah am Team – dort soll Handlungsfähigkeit hergestellt werden“, „Ohne Eskalation geht nichts weiter“, „Wir müssen halt mehr leisten“.
- Motivation : Am Anfang hohe Identifikation, später Frustration, Erschöpfung, Rückzug oder zynischer Humor („Das ist halt bei uns so“).
Was das für Führungskräfte im Mittelstand bedeutet
- Wo erwarte ich von diesen Rollen echten Impact auf die Wertschöpfung – und ist dafür die Rolle ausreichend klar?
- Wissen diese Menschen, welche Entscheidungen sie allein treffen sollen, welche gemeinsam und welche bewusst nicht sie treffen?
- Unterstützen unsere Strukturen und Prozesse (z.B. RFC, Delegation Board, Rollen-Canvas) diese Klarheit – oder verstärken sie das Chaos?
- Rollenklarheit schaffen
Gemeinsam mit Rolleninhaber:in ein Rollen-Canvas nutzen (Purpose, Ziele/OKRs, Verantwortlichkeiten, Entscheidungen, Aufgaben, Kompetenzen, Schnittstellen, Do’s & Don’ts). - Entscheidungsarchitektur explizit machen
Mit einfachen Decision-Matrizen oder RACI klären: Wer entscheidet was? Wer wird involviert? Wer wird informiert? - RFC als Standard etablieren
Für wiederkehrende, relevante Entscheidungen in Architektur, Organisation und Prozessen – nicht für jede Kleinigkeit, aber für Themen, die sonst in Dauerschleifen hängen.
Und wie gehen Lead-Rollen selbst damit um?
- Unsichtbare Verantwortung sichtbar machen Sammle, welche Erwartungen faktisch an dir hängen. Das ist die Basis für ein ehrliches Gespräch mit deiner Führungskraft.
- Entscheidungsgrenzen aktiv verhandeln Frage explizit: „Welche Entscheidungen erwarten Sie von mir? Was soll ich nicht entscheiden? Wann soll ich eskalieren?“
- RFC als Werkzeug ins Spiel bringen Nutze ein RFC-Format für ein konkretes Problem (z.B. Meetingstruktur, Oncall, Architekturentscheidung) und lade relevante Rollen zur Kommentierung ein.
- WiP und Kapazität adressieren Sprich offen über parallele Initiativen und Kapazität: „Wenn wir diese drei Projekte gleichzeitig fahren, sinkt unsere Wirksamkeit – welches priorisieren wir?“
weiterführende Themen
Lead-Rollen · Tech-Lead Rolle · Teamlead · Projektleitung · Scrum Master · Rollenklarheit · Rollen-Canvas · Entscheidungsarchitektur · Delegation Board · RFC-Prozess · Decision-Matrix · Work-in-Progress-Limits · Agile Leadership · systemische Organisationsentwicklung · 2-Cycles-Modell · Strukturen und Umfeld · Weltsicht und Motivation · Mittelstand · Produktentwicklung · Engineering Leadership