Refactoring Orgs

Das Wort "Product" leistet in vielen "Product Managern" dieser Tage ziemliche Schwerarbeit. Streich es weg und schau, was übrig bleibt. Wenn die Antwort Koordination, Meetings, Jira-Storys schreiben und Stakeholder-Alignment lautet, hast du keinen Product Manager eingestellt. Du hast einen internen Bürokraten mit einem hübscheren Titel eingestellt. Die Entscheidungen fallen woanders: weiter oben.

Du erkennst es in den Stellenbeschreibungen. Wenn auf "Product Manager" ein Komma folgt und eine Liste an Verantwortlichkeiten, die auch der Job von irgendwem anders sein könnten, wird das Produkt nicht gemanagt. Es wird beschrieben. Inzwischen gibt es "technische" Product Manager (was auch immer das heißen soll), und ich habe sogar schon einen "Product Manager für Sales" gesehen (sic!). In manchen Organisationen hat das Verhältnis von Product Managern zu anderen Rollen absurde Formen angenommen. Ich sag's ungern: zu viele Product Manager machen eine Organisation dysfunktional.

Die dysfunktionalste Form ist das Poolen. PMs über mehrere Teams zu poolen, ist das, was Führung macht, wenn sie sich nicht entscheiden kann oder will, welches Produkt am wichtigsten ist und wer für dessen Erfolg verantwortlich sein soll. Das ist ein ausweichendes Buchhaltungsmanöver, keine Strategie. Du kannst behaupten, du hättest Product Management aufgesetzt, ohne den Preis dafür zu zahlen, dich auf eine Wette festzulegen. Das Organigramm nennt es geteilte Kapazität. In Wirklichkeit ist eine Gruppe von Product Managern jetzt für eine noch größere Anzahl von Dingen verantwortlich, zu denen sich niemand committed hat.

Du hast keine Probleme gelöst. Du hast sie nur von der Bilanz der Führungsebene weggeräumt und auf jemanden mit weniger Macht zum Widerspruch geladen. Es wird nicht funktionieren, und die Spannungen sind trotzdem da - du spürst sie nur nicht mehr direkt.

Warum entscheiden sich Führungskräfte trotzdem für gepoolte PMs statt für konkrete Produktverantwortung? Entweder weil:

• Geteilte Verantwortung den ermöglicht, was ich "Teflon-Modus" nenne: die Führungskraft behält alle wichtigen Entscheidungsrechte (=sagt den PMs direkt, was zu tun ist), mit dem netten Nebeneffekt, dass sie den Pool an PMs für jedes Scheitern verantwortlich machen kann (weil auf dem Papier sind sie es ja!).
• Geteilte Verantwortung braucht keine Strategie: die Führungskraft muss keine überzeugende Strategie erarbeiten, wenn das Leben aus einer endlosen Serie spontaner Pivots besteht (=du darfst deine Meinung oft ändern, ohne zur Rechenschaft gezogen zu werden).

Früher oder später werden die Spannungen für die gepoolten PMs und die Teams unerträglich. Wenn du Glück hast, weist irgendwer die Führungskraft darauf hin. Was dann unvermeidlich passiert, ist das, was ich "Leadership-Zirkus" nenne: eine externe (meistens, manchmal auch interne) Beratung wird engagiert, um Leitlinien und ein gemeinsames Verständnis davon zu etablieren, was es heißt, Menschen zu führen. Denn aus Sicht der Führungskraft ist ja alles die Schuld der PMs. Wenn Dinge in ihrem Bereich nicht funktionieren, muss das an deren mangelnder Führungsqualität liegen, oder?

Vor ein paar Wochen habe ich dem Führungsteam einer anderen Firma eine Tour durch unser Unternehmen gegeben. Als es zum Q&A-Teil kam, war ihre erste Frage: "Wo sind eure Führungsprinzipien?". Sie erzählten mir, sie seien kürzlich von 25 auf 45 Leute gewachsen, überall gäbe es Spannungen, das Product Management sei gepoolt, und sie hätten gerade einen externen Berater engagiert, um "Führung zu fixen".

Zu ihrer Überraschung habe ich ihnen das gesagt: Führungskräfte engagieren Berater tendenziell nur dann, wenn die Berater Probleme woanders lösen. Was nicht unbedingt die Probleme sind, die die Spannungen verursachen. Tatsächlich rühren sie oft nicht mal an den eigentlichen Ursachen. Besonders dann nicht, wenn diese die eigenen Interaktionen der Führungskraft, ihren eigenen Teil des Organigramms und ihren eigenen Delegationsfluss in Frage stellen würden. In über 25 Jahren in der Industrie hatte ich nie das Glück, eine Führungskraft zu erleben, die reflektiert genug war, das durchzuziehen. Es mag sie geben, aber ich glaube, sie sind sehr selten. Also, was die meisten Führungskräfte tun: anstatt einen Schritt zurückzutreten und Verantwortung an konkrete Produkte zu delegieren, unterschreiben sie ein riesiges Budget für einen Leadership-Zirkus, an dem sie selbst bequemerweise nie teilnehmen werden. Wir reden von Dutzenden Meetings und Workshops mit allen in einer Führungsposition unterhalb der Führungskraft. Jeder darf mitreden, aber die eigentlichen Probleme werden nie angesprochen. Dieser mehrstufige "Prozess" wird meistens begleitet von einem endlosen Strom hübsch designter Powerpoints, per Mail verteilt an alle Beteiligten. Am Ende spuckt er sechs Monate später schön designte Poster mit offiziellen Führungsprinzipien aus.

Ich habe diese Poster in vielen Organisationen gesehen (ich darf manchmal andere Orgs besuchen, um zu lernen). Was mich am meisten trifft, ist ihre Gleichheit, dass sie alle unheimlich ähnlich sind. Die Führungskräfte sind meistens ziemlich stolz darauf, aber wenn du mit ihren HR-Leuten sprichst, geben die zu, dass sie nie jemand liest und niemandem helfen. Was diese Poster tun, ist, den Opfern die Schuld zu geben - den Opfern von Teflon-Modus, unklarer Produktverantwortung und ausweichenden Buchhaltungsmanövern.

Versteh mich nicht falsch - ich bin nicht grundsätzlich gegen diese Poster. In manchen Fällen mag es tatsächlich helfen, aufzuschreiben, was man von Leuten erwartet (gegen "sei nett zu anderen" werde ich nicht argumentieren). Ich glaube nur nicht, dass sie irgendwelche echten Probleme lösen. Wenn ich sie an einer Firmenwand sehe, behandle ich sie als Beweis für Delegationsentscheidungen, die jemand nicht getroffen hat.

TL;DR: Echtes Product Management ist untrennbar mit einem konkreten Produkt verbunden. Verdünn die Verantwortung, und du bekommst Beschäftigungstherapie mit einer Roadmap obendrauf. Pool keine PMs. Und "bitte, bitte" klatsch den Titel "Product Manager" nicht auf alles, was eine Roadmap hat.