Kein PM im Team: Was soll ein Senior eigentlich tun?

Ich habe kürzlich meine Probezeit bestanden, und in einem 1-on-1 sagte mein Manager: „Ich würde mir wünschen, dass du proaktiver Produktprobleme erkundest."

Das hat mich überrascht. Ich habe jeden Tag Code geschrieben, Issues gefixt und Projekte vorangetrieben. Wie war das nicht proaktiv genug? Es hat eine Weile gedauert, bis ich verstanden habe, was er eigentlich meinte.

Alles läuft gleichzeitig

Die Probezeit zu bestehen bedeutete nicht weniger Druck. Im Gegenteil — es bedeutete, noch mehr Dinge gleichzeitig zu jonglieren:

Punkt	Art	Was ich kontrollieren kann
Issue-Fixes	Tägliche Arbeit, Output wird teilweise nach Menge gemessen	Gleichmäßiges Tempo halten
Projekt A	Ein offizielles Projekt, aber die User-Seite bestätigt Anforderungen nur langsam	Begrenzt — hauptsächlich auf Antworten warten
Produktrecherche	Proaktiv nach Verbesserungsmöglichkeiten für das Produkt suchen	Wann liefern, wie präsentieren, wie berichten

Wenn man an einem einzigen Tag zwischen drei oder mehr Dingen wechselt, ist das Erschöpfende nicht die Stunden. Es ist das ständige Context Switching.

Dann wurde mir klar: Wir haben keinen PM

Das wusste ich vom ersten Tag an, aber ich hatte nie wirklich durchdacht, was das bedeutet.

Wir haben einen BA (Business Analyst), der sich um die Anforderungsanalyse kümmert, aber niemand kümmert sich wirklich um Fragen wie: Wo steht das gerade? Wer ist geblockt? Sollten wir umpriorisieren?

In meiner vorherigen Firma hat der PM oder Tech Lead das alles übernommen. Ich musste nur den Backlog prüfen, Prioritäten bestätigen, Produktanforderungen klären und mich aufs Coden konzentrieren. Die Spec kam rein, ich habe gebaut. Wenn ich feststeckte, habe ich es dem PM gesagt, und der hat den Rest erledigt.

Jetzt gibt es diese Rolle nicht mehr. Wer übernimmt das also?

Der Senior.

Senior ist nicht PM, aber du brauchst Ownership

Am Anfang habe ich es nicht verstanden. Ich bin Ingenieur — warum sollte ich Usern wegen Antworten hinterherlaufen, proaktiv Blocker melden oder Prioritäten mit meinem Manager abstimmen? Ist das nicht PM-Arbeit?

Aber das bedeutet nicht, dass ein Senior den PM ersetzen soll, indem er die Roadmap des Teams übernimmt, funktionsübergreifende Koordination macht oder den Fortschritt aller anderen verfolgt. Der eigentliche Punkt ist einfacher: Du kannst Blocker in deiner eigenen Arbeit nicht behandeln, als wären sie das Problem von jemand anderem.

Als ich die beiden verglichen habe, wurde der Unterschied klarer:

	PM	Senior
Wessen Fortschritt managen	Das ganze Team	Deine eigenen Arbeitslinien
Entscheiden, was gebaut wird	Roadmap, Prioritäten	Nicht entscheiden, aber abstimmen
Stakeholder verfolgen	Alle Beteiligten	Deine eigenen Blocker
Verantwortlich gegenüber	Geschäftszielen	Den Features, die du verantwortest

Ein Senior muss keine anderen Leute managen. Du musst nur deine eigenen drei oder vier Linien am Laufen halten. Blocker proaktiv melden, statt schweigend zu warten. Meinungen zu den Features haben, die du verantwortest, statt nur auf Anweisungen zu warten.

Das nennt sich Ownership, nicht PM.

Es liegt nicht daran, dass mein vorheriger Job zu einfach war

Einen Moment lang fragte ich mich, ob meine alte Firma einfach niedrigere Erwartungen an Seniors hatte. Aber je mehr ich darüber nachdachte, desto mehr wurde mir klar, dass das nicht das Problem war. Die Umgebungen waren einfach unterschiedlich.

Meine vorherige Firma hatte einen PM, der mich vor Koordinationsarbeit abschirmte, und die Produktlinie war einfacher. Dort wurde „Senior" eher technisch definiert: Wenn du schwierige Probleme lösen konntest, reichte das. In meiner aktuellen Umgebung gehört es auch zum Job, den Produktfortschritt voranzutreiben, weil es niemand anders für dich tun wird.

In einem schlanken Team ist das normal. Es ist nicht unvernünftig. Ich bin nur noch nicht daran gewöhnt.

Was ich tatsächlich getan habe

Nachdem ich das verstanden hatte, habe ich ein paar Änderungen vorgenommen:

Priorisieren und mit dem Manager abstimmen. Ich habe alles nach Priorität aufgelistet und gefragt: „Passt diese Reihenfolge für dich?" Es ist nur eine Nachricht, aber es ändert die Haltung von passivem Warten auf Anweisungen zu aktivem Management meiner eigenen Arbeit.

Wenn geblockt, Linie wechseln, aber dokumentieren. Wenn der User bei Projekt A nicht antwortet, pinge ich einmal pro Woche und hinterlasse eine Papierspur. Mein Manager weiß, dass der Blocker nicht auf meiner Seite liegt, und ich kann die freigewordene Zeit nutzen, um die Produktrecherche voranzutreiben.

Nicht zu oft Context Switching machen. Prioritäten nutzen, um zu entscheiden, woran heute gearbeitet wird, statt alles ein bisschen anzufassen. Geblockte Linien dokumentieren, beiseitelegen und zurückwechseln, sobald sie entblockt werden.

Abschließender Gedanke

Das alles klingt grundlegend, aber für einen Ingenieur, der es gewohnt ist, dass ein PM die Koordination übernimmt, braucht es Zeit, sich anzupassen. Unter Druck kann es sich anfühlen, als würde man Arbeit machen, die einem nicht gehört. Aber zumindest in einem Team ohne PM ist das Teil dessen, was Senior sein bedeutet.

Nebenbei bemerkt: Die Gedanken hinter diesem Beitrag habe ich zuerst durch Gespräche mit AI sortiert und dann über ein persönliches System verfolgt, das ich für tägliches Logging und Feedback gebaut habe — ich nenne es Pasiv. Vibe Coding bedeutet nicht nur, AI zum Bauen von Projekten zu nutzen. Es beinhaltet auch, damit zu entwirren, wo man gerade steht.