Zu viele Projekte gleichzeitig? So gewinnen Engineering Manager wieder Kontrolle

Zu viele Projekte gleichzeitig.
Und jedes davon ist angeblich Prio 1.

• Das C-Level erwartet Tempo.
• Stakeholder pushen neue Initiativen.
• Gleichzeitig frisst BAU dein Team auf.
• Und im Sprint Planning wird aus Fokus eine Wunschliste.

Wenn dir das bekannt vorkommt, liegt es nicht an deinem Team.
Und auch nicht an mangelnder Disziplin.

Das eigentliche Problem ist strukturell.

Viele Engineering Manager versuchen, operative Überlastung mit noch besserem Task-Management zu lösen. Sie optimieren Tickets, schärfen User Stories, führen zusätzliche Sync-Meetings ein. Doch solange im Portfolio zu viele Projekte gleichzeitig laufen, bleibt dein Team im Dauer-Kontextwechsel gefangen.

Die Folgen sind absehbar:

• Kein verlässliches Sprint Commitment
• Sinkende Motivation im Team
• Politische Diskussionen statt klarer Prioritäten
• Permanente Rechtfertigung gegenüber Stakeholdern

„Zu viele Projekte gleichzeitig“ ist kein individuelles Versagen.
Es ist ein Priorisierungs- und Operating-Model-Problem.

In diesem Guide zeige ich dir:

• warum Engineering Teams nicht an mangelnder Performance scheitern, sondern an fehlender Systemklarheit
• wie du Portfolio, Initiativen und Team-Backlog sauber voneinander trennst
• wie du Stakeholder-Druck souverän moderierst
• und wie du wieder echte Kontrolle über Fokus, Kapazität und Commitment gewinnst

Wenn du als Engineering Manager das Gefühl hast, dass dein Team eigentlich gut ist, aber trotzdem nie wirklich fertig wird, dann ist dieser Artikel für dich.

Lass uns das Problem dort lösen, wo es entsteht. Nicht im Sprint. Sondern im System.

Warum „zu viele Projekte gleichzeitig“ kein Kapazitätsproblem ist

Viele Engineering Manager reagieren reflexartig, wenn sie merken, dass zu viele Projekte gleichzeitig laufen.

Sie denken:

• Wir brauchen mehr Entwickler.
• Wir müssen besser planen.
• Das Team muss effizienter werden.
• Wir müssen unsere Velocity steigern.

Doch in den meisten Fällen ist das nicht die Ursache.

Das Missverständnis: Mehr Kapazität löst Überlastung

Wenn zu viele Projekte gleichzeitig gestartet werden, entsteht kein lineares Kapazitätsproblem, sondern ein exponentielles Kontextwechsel-Problem.

Ein einfaches Beispiel:

• Drei parallele Initiativen
• Mehrere Stakeholder
• Laufende BAU-Anfragen
• Zusätzlich ungeplante Ad-hoc-Themen

Das Team arbeitet nicht an drei Dingen.
Es arbeitet an 15 offenen Gedankenspuren.

Jeder Kontextwechsel kostet Zeit.
Jede neue Priorität erzeugt Unsicherheit.
Jede parallele Initiative verlängert Durchlaufzeiten.

Das Ergebnis:

Mehr Arbeit in Progress.
Weniger abgeschlossene Ergebnisse.
Sinkende Planbarkeit.

Und genau hier beginnt der Teufelskreis.

Warum gute Teams trotzdem scheitern

Du kannst ein starkes, motiviertes Engineering-Team haben.
Mit klarer Sprint-Struktur.
Mit guter technischer Qualität.

Wenn aber zu viele Projekte gleichzeitig auf Portfolio-Ebene freigegeben werden, gerät das Team automatisch in einen Zustand permanenter Reaktivität.

Das Problem entsteht nicht im Sprint Planning.

Es entsteht davor.

Typische Symptome:

• Sprint-Ziele werden regelmäßig angepasst
• Scope wächst während des Sprints
• Stakeholder erwarten sofortige Reaktionen
• Backlog-Prioritäten ändern sich wöchentlich

Viele Führungskräfte interpretieren das als Disziplinproblem. In Wahrheit fehlt ein klares Priorisierungs- und Entscheidungsmodell.

Das Prio-1-Paradox

In vielen Organisationen gibt es offiziell mehrere Prio-1-Initiativen. Rein logisch ist das unmöglich.

Wenn alles höchste Priorität hat, hat nichts mehr Priorität.

Doch in der Realität passiert genau das:

• Vertrieb verspricht Features
• Marketing startet Kampagnen
• Produkt pusht strategische Roadmap-Themen
• Management reagiert auf Marktbewegungen

Und plötzlich laufen zu viele Projekte gleichzeitig, ohne dass jemand aktiv entschieden hat, was bewusst nicht gemacht wird.

Priorisierung bedeutet nicht, Dinge zu ordnen.
Priorisierung bedeutet, Dinge auszuschließen.

Das ist unbequem.
Und genau deshalb wird es oft vermieden.

Warum „zu viele Projekte gleichzeitig“ ein Systemproblem ist

Wenn dein Team überlastet wirkt, solltest du nicht zuerst auf Velocity oder Effizienz schauen.

Stell dir stattdessen diese Fragen:

• Wie viele Initiativen laufen offiziell parallel?
• Wie hoch ist der Anteil ungeplanter BAU-Arbeit?
• Wer entscheidet über neue Themen?
• Gibt es eine Regel, wie viele Projekte gleichzeitig aktiv sein dürfen?

In den meisten Fällen lautet die ehrliche Antwort:

Nein.

Und genau dort liegt die Ursache.

Ohne ein klares System entstehen automatisch zu viele Projekte gleichzeitig. Nicht aus böser Absicht, sondern aus fehlender Entscheidungsstruktur.

Die drei Ebenen der Kontrolle: Portfolio, Initiative und Team

Wenn zu viele Projekte gleichzeitig laufen, wird häufig versucht, das Problem auf Teamebene zu lösen.

Besseres Refinement.
Strengere Sprint-Ziele.
Mehr Disziplin im Planning.

Doch Überlastung entsteht selten im Sprint.
Sie entsteht eine Ebene darüber.

Um wieder Kontrolle zu gewinnen, musst du drei Ebenen sauber voneinander trennen:

1. Portfolio-Ebene
2. Initiativen-Ebene
3. Team-Backlog-Ebene

Solange diese Ebenen vermischt werden, bleibt dein Team im Dauerstress.

1. Portfolio-Ebene: Was darf überhaupt gleichzeitig laufen?

Hier entsteht das Problem „zu viele Projekte gleichzeitig“.

Auf Portfolio-Ebene wird entschieden:

• Welche Initiativen starten?
• Welche pausieren?
• Welche bekommen echte Priorität?
• Welche warten bewusst?

In vielen Organisationen gibt es keine harte Begrenzung. Initiativen werden gestartet, ohne alte zu beenden.

Das führt zu:

• Parallelität ohne Fokus
• Politischer Priorisierung
• Überforderung auf Teamebene

Ein zentrales Prinzip lautet:

Begrenze aktive Initiativen.

Ein einfaches Modell dafür ist:

Now
Next
Somewhen

Nur Initiativen in „Now“ dürfen aktiv Ressourcen binden.
„Next“ wird vorbereitet.
„Somewhen“ bleibt bewusst geparkt.

Ohne eine solche Struktur entstehen automatisch zu viele Projekte gleichzeitig.

Und dein Team zahlt den Preis.

2. Initiativen-Ebene: Von Idee zu strukturierter Umsetzung

Selbst wenn das Portfolio begrenzt ist, kann Chaos entstehen, wenn Initiativen unsauber definiert sind.

Typische Probleme:

• Unklarer Scope
• Keine klare Zieldefinition
• Keine Definition von „fertig“
• Risiken werden nicht transparent gemacht

Das führt dazu, dass Initiativen während der Umsetzung wachsen.

Scope Creep ist keine Disziplinfrage.
Es ist ein Definitionsproblem.

Bevor eine Initiative ins „Now“ verschoben wird, sollten mindestens folgende Fragen beantwortet sein:

• Welches konkrete Ziel verfolgen wir?
• Woran messen wir Erfolg?
• Welche Abhängigkeiten existieren?
• Welche Risiken sind sichtbar?

Ohne diese Klarheit werden selbst drei parallele Initiativen zu einem Belastungsfaktor.

3. Team-Backlog-Ebene: Das operative Schutzschild

Erst auf dieser Ebene arbeitet dein Team.

Und hier wird oft versucht, strukturelle Probleme zu kompensieren.

Das Backlog wird zur politischen Arena.
Das Sprint Planning zum Verhandlungstermin.
Das Commitment zur Schätzung mit Bauchgefühl.

Wenn zu viele Projekte gleichzeitig aktiv sind, kann dein Team kein stabiles Commitment geben.

Ein stabiles Team-Setup braucht:

• Klar priorisierte Initiativen
• Begrenzte Work in Progress
• Sichtbare BAU-Quote
• Eine echte Definition of Ready

Besonders wichtig ist die BAU-Transparenz.

Viele Teams unterschätzen, wie viel Kapazität für Support, Bugs, Abstimmungen und Ad-hoc-Anfragen draufgeht.

Wenn BAU nicht explizit geplant wird, entsteht der Eindruck, das Team liefere zu wenig.

In Wahrheit arbeitet es nur unsichtbar.

Warum diese Trennung so entscheidend ist

Wenn zu viele Projekte gleichzeitig laufen, versucht das System, sich selbst zu stabilisieren.

Das Team arbeitet länger.
Der Engineering Manager moderiert Konflikte.
Stakeholder eskalieren.

Doch ohne strukturelle Begrenzung auf Portfolio-Ebene bleibt das Problem bestehen.

Kontrolle entsteht nicht durch mehr Einsatz.
Kontrolle entsteht durch Design.

Im nächsten Abschnitt gehen wir konkret in die Umsetzung: Wie du in vier Schritten wieder Fokus herstellst, Stakeholder synchronisierst und dein Sprint Commitment schützt.

Schritt für Schritt zurück zur Kontrolle

Wenn zu viele Projekte gleichzeitig laufen, hilft keine theoretische Diskussion.
Du brauchst ein klares Vorgehen.

Die gute Nachricht: Du musst nicht alles gleichzeitig ändern.
Du brauchst nur die richtige Reihenfolge.

Hier ist ein vierstufiger Ansatz, der in der Praxis funktioniert.

Schritt 1: Radikale Transparenz herstellen

Bevor du priorisierst, musst du sichtbar machen, was wirklich läuft.

In vielen Organisationen weiß niemand genau:

• Wie viele Initiativen sind offiziell aktiv?
• Wie viele Themen sind zusätzlich im Backlog versteckt?
• Wie viel BAU-Arbeit frisst Kapazität?
• Wie hoch ist die reale Work in Progress?

Schreibe alles auf den Tisch.

Erstelle eine Liste aller aktiven Initiativen.
Keine politische Filterung. Keine Schönfärberei.

Dann stelle drei einfache Fragen:

1. Wie viele dieser Initiativen sind wirklich gleichzeitig aktiv?
2. Welche davon haben ein klares Ziel und messbaren Outcome?
3. Welche könnten pausiert werden, ohne dass das Unternehmen kollabiert?

In fast allen Fällen wird sichtbar:
Es laufen zu viele Projekte gleichzeitig.

Transparenz ist unbequem.
Aber ohne Transparenz gibt es keine Priorisierung.

Schritt 2: Trade-off-Gespräche erzwingen

Hier trennt sich Management von Leadership.

Wenn eine neue Initiative gestartet werden soll, muss eine andere weichen.

Kein „wir machen das zusätzlich“.
Kein „nur kurz einschieben“.

Jede neue Priorität braucht eine bewusste Verdrängung.

Das verändert die Gesprächsdynamik mit Stakeholdern massiv.

Statt zu sagen:
„Wir versuchen es reinzuquetschen“

Sagst du:
„Welche bestehende Initiative soll dafür pausieren?“

Plötzlich wird Priorisierung real.

Viele Organisationen vermeiden genau diese Gespräche.
Deshalb entstehen dauerhaft zu viele Projekte gleichzeitig.

Deine Aufgabe als Engineering Manager ist nicht, alles möglich zu machen.
Deine Aufgabe ist, klare Entscheidungen zu erzwingen.

Schritt 3: Die BAU-Quote sichtbar planen

Ein häufiger Grund, warum zu viele Projekte gleichzeitig scheitern, ist die unsichtbare BAU-Arbeit.

• Support.
• Bugs.
• Technische Schulden.
• Abstimmungen.
• Ad-hoc-Anfragen.

Wenn du diese Arbeit nicht explizit planst, entsteht die Illusion freier Kapazität. Definiere eine feste BAU-Quote.

Zum Beispiel:

• 30 Prozent der Sprint-Kapazität sind für BAU reserviert.
• Nur 70 Prozent stehen für Initiativen zur Verfügung.

Das ist kein Zeichen von Ineffizienz.
Es ist professionelles Erwartungsmanagement.

Stakeholder reagieren anfangs irritiert.
Doch langfristig steigt die Planbarkeit.

Schritt 4: Das Sprint Commitment schützen

Wenn zu viele Projekte gleichzeitig laufen, bricht das Commitment im Sprint.

Nicht weil das Team schlecht ist.
Sondern weil Scope während der Umsetzung wächst.

Schütze den Sprint konsequent.

Das bedeutet:

• Keine ungeplanten Scope-Erweiterungen.
• Keine stillen Prioritätswechsel.
• Keine versteckten Zusatzaufgaben.

Wenn neue Themen entstehen, kommen sie ins Backlog.
Nicht direkt in den laufenden Sprint.

Diese Klarheit erzeugt Stabilität.
Und Stabilität erzeugt Vertrauen.

Was sich dadurch verändert

Wenn du diese vier Schritte konsequent gehst:

• Die Anzahl aktiver Initiativen sinkt.
• Durchlaufzeiten verkürzen sich.
• Das Team gewinnt Fokus zurück.
• Stakeholder-Diskussionen werden sachlicher.
• Dein Sprint Commitment wird verlässlicher.

Das zentrale Prinzip lautet:

Nicht mehr Projekte starten.
Sondern weniger gleichzeitig.

Genau dort liegt der Hebel.

Fallbeispiel: Von sechs parallelen Initiativen zu echtem Fokus

Theorie überzeugt. Ergebnisse überzeugen mehr.

Hier ist ein typisches Szenario, das viele Engineering Manager kennen:

Ausgangslage: Zu viele Projekte gleichzeitig und kein klares Commitment

Ein mittelgroßes Engineering-Team, 8 Entwickler.

Offiziell liefen:

• 3 strategische Initiativen
• 2 vertriebsgetriebene Feature-Projekte
• 1 technische Modernisierung

Zusätzlich:

• Rund 35 Prozent BAU-Arbeit
• Wöchentliche Ad-hoc-Anfragen
• Mehrere Abhängigkeiten zu anderen Teams

Symptome:

• Kein Sprint wurde vollständig committed geliefert
• Scope wurde regelmäßig im Sprint angepasst
• Stakeholder eskalierten wegen Verzögerungen
• Das Team war frustriert

Die Führungsebene interpretierte das als Delivery-Problem.

Die Realität war klar: Es liefen zu viele Projekte gleichzeitig.

Intervention: Struktur statt Heldentum

Statt Prozesse im Team weiter zu verschärfen, wurde eine Ebene höher angesetzt.

1. Portfolio-Transparenz

Alle Initiativen wurden sichtbar gemacht.
Nicht nur die strategischen, sondern auch die versteckten Themen – wer kennt sie nicht die so genannten U-Boot Projekte.

Ergebnis:
Sechs aktive Initiativen bei realistisch zwei parallelen Kapazitäten.

2. Harte Priorisierung

Gemeinsam mit Stakeholdern wurde entschieden:

• Zwei Initiativen bleiben aktiv
• Zwei wandern in „Next“
• Zwei werden bewusst pausiert

Wichtig:
Nicht das Team priorisierte.
Die Entscheidung lag auf Portfolio-Ebene.

3. BAU-Quote fixieren

Es wurde eine feste BAU-Quote von 30 Prozent definiert.

Dadurch sank die theoretische Feature-Kapazität. Aber die Prognosequalität stieg.

4. Sprint-Schutz

Neue Themen durften nicht mehr direkt in laufende Sprints einfließen.
Stattdessen wurden sie gesammelt und in der nächsten Priorisierungsrunde bewertet.

Ergebnis: Weniger Projekte, mehr Ergebnisse

Nach acht Wochen zeigten sich klare Effekte:

• Sprint Commitments wurden zu über 90 Prozent eingehalten
• Durchlaufzeiten verkürzten sich
• Stakeholder-Diskussionen wurden faktenbasierter
• Das Team berichtete deutlich weniger Stress

Interessanterweise wurde nicht mehr gearbeitet.
Es wurde weniger parallel gearbeitet.

Die Anzahl gestarteter Initiativen sank.
Die Anzahl abgeschlossener Initiativen stieg.

Die entscheidende Erkenntnis

Das Team war nie das Problem.

Die Struktur war es.

Solange zu viele Projekte gleichzeitig laufen, erzeugt das System automatisch Überlastung, Frust und politische Konflikte.

Wenn du als Engineering Manager Fokus designst, statt nur Delivery zu optimieren, verändert sich das gesamte System.

Die 5 häufigsten Fehler, die dazu führen, dass dauerhaft zu viele Projekte gleichzeitig laufen

Viele Organisationen wissen, dass sie ein Priorisierungsproblem haben.
Trotzdem wiederholt sich das Muster.

Warum?

Weil bestimmte Denkfehler systematisch auftreten.

Hier sind die fünf häufigsten Ursachen dafür, dass immer wieder zu viele Projekte gleichzeitig gestartet werden.

Fehler 1: Alles als Prio 1 akzeptieren

Der Klassiker.

• Vertrieb verspricht Features.
• Marketing plant Kampagnen.
• Produkt pusht strategische Initiativen.
• Management reagiert auf Marktbewegungen.

Jede Anfrage wird als dringend verkauft.

Wenn du als Engineering Manager keine klare Gegenstruktur etablierst, entsteht automatisch eine Liste aus „Top-Prioritäten“, die sich gegenseitig blockieren.

• Priorisierung bedeutet nicht, Dinge zu sortieren.
• Priorisierung bedeutet, bewusst Nein zu sagen.

Solange das nicht passiert, werden immer wieder zu viele Projekte gleichzeitig aktiviert.

Fehler 2: Keine Begrenzung der parallelen Initiativen

Viele Organisationen definieren:

• Roadmaps
• Quartalsziele
• OKRs

Aber sie definieren keine harte Grenze für parallele Initiativen.

Ohne Limit entsteht unbegrenzte Work in Progress.

Das Problem:
Je mehr Projekte gleichzeitig laufen, desto länger dauert jedes einzelne.

Mehr Parallelität erzeugt weniger Output.

Ein einfaches Prinzip hilft:

Begrenze aktive Initiativen bewusst.

Nicht mehr als zwei oder drei gleichzeitig, abhängig von Teamgröße und BAU-Quote.

Fehler 3: BAU-Arbeit ignorieren

Einer der größten versteckten Treiber für Überlastung.

Support-Anfragen.
Bugs.
Abstimmungen.
Technische Schulden.

Wenn BAU nicht explizit geplant wird, entsteht eine Illusion freier Kapazität.

Dann wirken neue Initiativen machbar.
In der Realität werden sie nur gestapelt.

Das Ergebnis:

Zu viele Projekte gleichzeitig bei faktisch weniger verfügbarer Zeit.

Professionelle Engineering Manager machen BAU sichtbar.
Und planen sie aktiv ein.

Fehler 4: Scope wächst unkontrolliert

Selbst wenn die Anzahl paralleler Initiativen reduziert wird, kann Überlastung entstehen, wenn Scope nicht stabil bleibt.

Typische Aussagen:

• „Können wir das noch schnell ergänzen?“
• „Das ist nur eine kleine Erweiterung.“
• „Das brauchen wir unbedingt für den Launch.“

Viele kleine Erweiterungen summieren sich.

Und plötzlich ist eine Initiative doppelt so groß wie geplant.

Ohne klare Definition von Ziel, Umfang und Erfolgskriterien wächst jede Initiative.

Und damit steigt die Belastung, obwohl formal nicht mehr Projekte gleichzeitig laufen.

Fehler 5: Das Team soll das System kompensieren

Wenn Delivery nicht funktioniert, wird oft auf Teamebene nachjustiert:

• Mehr Meetings
• Strengere Planungsregeln
• Engmaschigere Kontrolle
• Druck auf Velocity

Doch kein Team kann dauerhaft ein strukturell überladenes Portfolio kompensieren.

Wenn zu viele Projekte gleichzeitig aktiv sind, wird jede operative Optimierung nur Symptombehandlung bleiben.

Systemische Probleme brauchen systemische Lösungen.

Warum diese Fehler so hartnäckig sind

Weil sie politisch bequem sind.

Es ist einfacher:

• Ein weiteres Projekt zu starten
• Eine kleine Erweiterung zu akzeptieren
• BAU nicht explizit zu machen

Als harte Trade-offs zu moderieren.

Doch genau hier entsteht Führung.

Engineering Leadership bedeutet nicht, alles möglich zu machen.
Es bedeutet, Fokus zu schützen.

Was gute Engineering Manager anders machen

Viele Führungskräfte reagieren auf „zu viele Projekte gleichzeitig“ mit operativer Optimierung.

Exzellente Engineering Manager gehen einen Schritt zurück.

Sie verstehen:

• Das Problem ist nicht Arbeitsmenge.
• Das Problem ist fehlendes Design.

Hier sind die Unterschiede, die wirklich zählen.

1. Sie verteidigen Fokus aktiv

Durchschnittliche Manager versuchen, alle Erwartungen zu erfüllen.

Exzellente Manager stellen eine Gegenfrage:

„Was machen wir bewusst nicht?“

Sie akzeptieren keine zusätzliche Initiative ohne klare Verdrängung.
Sie lassen sich nicht in „nur noch schnell“ Gespräche ziehen.

Fokus entsteht nicht durch Wunschdenken.
Fokus entsteht durch konsequente Begrenzung.

Wenn zu viele Projekte gleichzeitig starten sollen, verschieben sie die Diskussion von „Wie schaffen wir das?“ zu „Was priorisieren wir wirklich?“

2. Sie machen Kapazität sichtbar statt Versprechen zu geben

Viele Engineering Manager geraten unter Druck, schnelle Zusagen zu machen.

Exzellente Manager sprechen über Kapazität in Zahlen:

• Verfügbare Teamkapazität
• BAU-Anteil
• Aktive Initiativen
• Work in Progress

Sie argumentieren mit Transparenz, nicht mit Bauchgefühl.

Wenn Stakeholder sehen, dass bereits drei Initiativen parallel laufen und 30 Prozent der Kapazität durch BAU gebunden sind, verändert sich die Gesprächsbasis.

Statt Emotionen entstehen faktenbasierte Entscheidungen.

3. Sie führen Trade-off-Gespräche statt To-do-Listen

In Organisationen mit zu vielen Projekten gleichzeitig fehlt oft ein Ort für echte Priorisierungsentscheidungen.

Exzellente Engineering Manager schaffen diesen Ort.

Sie moderieren Gespräche, in denen nicht über Aufgaben gesprochen wird, sondern über Konsequenzen:

• Wenn wir A starten, pausieren wir B.
• Wenn wir Scope erweitern, verschiebt sich Timeline.
• Wenn wir neue Themen aufnehmen, sinkt Commitment-Stabilität.

Sie übersetzen Komplexität in Entscheidungsklarheit.

4. Sie bauen Systeme statt Heldengeschichten

In überlasteten Umfeldern entsteht häufig eine Kultur des Heroismus:

• Länger arbeiten
• Mehr Einsatz
• Wochenenden retten
• „Wir schaffen das schon“

Kurzfristig wirkt das beeindruckend.
Langfristig zerstört es Planbarkeit und Motivation.

Exzellente Engineering Manager setzen auf Struktur:

• Klare Portfolio-Grenzen
• Begrenzte parallele Initiativen
• Sichtbare BAU-Quote
• Geschütztes Sprint Commitment

Sie wissen:
Systeme skalieren. Heldentum nicht.

5. Sie verstehen ihre Rolle als Systemarchitekt

Ein entscheidender Perspektivwechsel:

Deine Aufgabe ist nicht primär Delivery-Optimierung.
Deine Aufgabe ist Systemgestaltung.

Wenn dauerhaft zu viele Projekte gleichzeitig laufen, liegt deine größte Hebelwirkung nicht im Daily, sondern im Portfolio-Design.

Exzellente Engineering Manager:

• Denken in Ebenen
• Moderieren Konflikte
• Designen Entscheidungsprozesse
• Schaffen Transparenz

Sie arbeiten am Rahmen, nicht nur an den Tickets.

Der Unterschied ist Haltung

Der Unterschied zwischen dauerhafter Überlastung und nachhaltigem Fokus ist keine Methode.

Es ist Führung.

Wenn du akzeptierst, dass dein Job nicht darin besteht, jede Anforderung möglich zu machen, sondern klare Priorisierung herzustellen, verändert sich dein gesamtes Handeln.

Zu viele Projekte gleichzeitig sind kein Naturgesetz.

Sie sind das Ergebnis von fehlender Begrenzung.

Und Begrenzung ist eine Führungsentscheidung.

Dein 5-Minuten-Fokus-Check: Laufen bei dir zu viele Projekte gleichzeitig?

Wenn du unsicher bist, ob dein Team wirklich strukturell überlastet ist, beantworte diese Fragen ehrlich.

Keine politische Antwort.
Keine optimierte Darstellung.
Nur Realität.

1. Wie viele Initiativen sind offiziell gleichzeitig aktiv?

Zähle nur die Initiativen, die tatsächlich Ressourcen binden.

Nicht Roadmap-Ideen.
Nicht strategische Visionen.
Sondern aktive Arbeit.

Wenn die Zahl höher ist als zwei bis drei parallele Initiativen pro Team, steigt die Wahrscheinlichkeit massiv, dass zu viele Projekte gleichzeitig laufen.

2. Wie hoch ist eure reale BAU-Quote?

Nicht geschätzt.
Sondern gemessen.

• Wie viele Stunden pro Sprint gehen in Support, Bugs, Abstimmungen?
• Wie viel ungeplante Arbeit taucht regelmäßig auf?

Wenn BAU nicht explizit eingeplant wird, überschätzt du automatisch deine Feature-Kapazität.

Und das führt dazu, dass neue Initiativen gestartet werden, obwohl faktisch keine freie Kapazität existiert.

3. Wer entscheidet über neue Themen?

Gibt es eine klare Regel?

Oder entstehen neue Initiativen durch:

• laute Stakeholder
• spontane Management-Impulse
• Eskalationen

Wenn es keinen klaren Entscheidungsprozess gibt, entstehen zwangsläufig zu viele Projekte gleichzeitig.

4. Wie stabil ist euer Sprint Commitment?

Wird Scope regelmäßig angepasst?
Werden Themen während des Sprints ergänzt?
Müssen Ziele oft neu verhandelt werden?

Instabilität im Sprint ist häufig ein Symptom von Portfolio-Überlastung.

Nicht von schlechter Planung.

5. Gibt es eine bewusste Grenze für parallele Initiativen?

Nicht implizit.
Nicht gefühlt.
Sondern explizit definiert.

Wenn es keine klare Obergrenze gibt, wird sie automatisch überschritten.

Wenn du bei mehreren Fragen gezögert hast

Dann laufen sehr wahrscheinlich zu viele Projekte gleichzeitig in deinem System.

Und das ist kein individuelles Versagen.

Es ist ein Designproblem.

Fazit: Kontrolle ist eine bewusste Entscheidung

Zu viele Projekte gleichzeitig entstehen nicht, weil Teams schlecht arbeiten.

Sie entstehen, weil:

• Priorisierung vermieden wird
• Trade-offs nicht moderiert werden
• BAU unsichtbar bleibt
• Parallelarbeit nicht begrenzt wird

Wenn du als Engineering Manager Fokus designst, statt Überlastung zu verwalten, verändert sich dein gesamtes System.

Weniger parallele Initiativen bedeuten:

• Kürzere Durchlaufzeiten
• Höhere Planbarkeit
• Weniger politische Konflikte
• Mehr Motivation im Team

Fokus ist kein Zufall.
Fokus ist Führung.