Es gibt immer mehr Produkte und immer weniger Produktmanager
(kitemaker.co)- Die Diskussion darüber, wie viele PMs ein Produktteam haben sollte, hat nach der Neuaufstellung der Produktmanagement-Organisation von Airbnb und nach Beispielen von Startups, die ohne PM wachsen, deutlich zugenommen
- Je mehr PMs es gibt, desto eher kann eine Struktur entstehen, in der Zeit eher für Projektmanagement und Roadmap-Updates als für den geschäftlichen Erfolg des Produkts aufgewendet wird
- In Teams mit erfahrenen Designern und Engineers muss PM-Arbeit nicht zwingend eine Vollzeitrolle sein; auch das Modell mit einem PM pro Team sollte je nach Situation neu bewertet werden
- Der erste PM wird meist dann eingestellt, wenn Gründer nicht mehr alle wichtigen Produktentscheidungen selbst mittragen können, typischerweise bei einer Größe von 50–100 Mitarbeitenden und 3–5 Produktteams
- Mehr PMs zu haben macht eine Organisation nicht automatisch produktorientiert und kann im Gegenteil das Produktverantwortungsgefühl von Designern und Engineers schwächen
Weniger PMs, breiter verteilte Produktverantwortung
- Die Debatte über den Bedarf an PMs wurde lebhafter nach der Neuaufstellung der Produktmanagement-Organisation von Airbnb und nach Artikeln über Startups, die auch ohne PM wachsen
- In vielen Unternehmen füllen PMs ihren Tag eher mit Aufgaben wie Projektmanagement und Roadmap-Updates, statt Produkte optimal auf das Geschäft auszurichten
- Im Allgemeinen sollte es weniger PMs als Produktteams geben; die Struktur, jedem Team einen eigenen PM zuzuordnen, sollte je nach Produkt- und Teamsituation überdacht werden
- Wenn viel Produktarbeit anfällt und das Team eher junior ist, kann ein dedizierter PM pro Team nötig sein
- In Teams mit erfahrenen Engineers und Designern muss die PM-Rolle nicht Vollzeit sein oder sollte es möglicherweise nicht sein
- Der richtige Zeitpunkt für die Einstellung des ersten PMs in einem Startup ist, wenn Gründer nicht mehr in alle wichtigen Produktentscheidungen eingebunden sein können
- Als grober Maßstab gelten meist 50–100 Mitarbeitende und 3–5 Produktteams
- Die übergreifende Produktstrategie sollte bereits klar sein, und der PM sollte darauf aufbauend an nachgelagerten Richtungsentscheidungen und Entscheidungen mitwirken
- Für die erste PM-Rolle ist ein Senior-PM besser geeignet als ein Junior-PM oder CPO
- Die Person kann mit dem Wachstum des Unternehmens später die CPO-Rolle übernehmen, aber die Gründer sollten faktisch weiterhin die Verantwortung für das Produkt tragen
Praktiken für produktorientierte Teams
- Produktverantwortung sollte sich nicht bei einem einzelnen PM bündeln; auch Design und Engineering müssen Nutzer und Produktkontext direkt verstehen
- Designer und Engineers sollten sich aktiv an der Produktgestaltung beteiligen und detaillierte Produktdiskussionen mitführen
- Ein PM sollte nicht allein für UX, Wireframes, Fortschrittsverfolgung, die Moderation von Stand-ups oder das alleinige Verfassen von PRDs/Spezifikationen zuständig sein
- Der Fokus des PM sollte auf der Formulierung der Produktvision, der Auswahl der richtigen Probleme, der Wahrung der Produktrichtung und der Abstimmung mit geschäftlichen Anforderungen liegen
- Michael Seibels „Guide to product development“ verweist auf Social Cam als Beispiel für die Umsetzung dieses Ansatzes
- Das Team sollte Kontext und Entscheidungsgrundlagen aktiv teilen
- Auch Design und Engineering sollten Zugang zu Nutzerfeedback haben
- Problemlösung sollte kein PM-zentrierter Prozess sein, sondern Zusammenarbeit zwischen Produkt, Design und Engineering
- Praktiken zum Aufbau produktorientierter Teams lassen sich in vier Punkte zusammenfassen
- Gemeinsam starten: Bevor Tickets oder Spezifikationen geschrieben und bevor Lösungen festgelegt werden, stimmen Design, Engineering und Produkt/Gründer gemeinsam Vorgehen und Plan ab
- Alle mit Nutzern in Kontakt bringen: Direkt an Nutzerforschung und Usability-Tests teilnehmen oder per Video-Streaming bzw. mit Tools wie Lookback beobachten, wie Nutzer das Produkt verwenden
- Auf das Team-Management achten: Wenn Leistung nach Anzahl geschlossener Tickets oder Story Points gemessen wird, richtet sich das Team auf Ticket-Abarbeitung statt auf ein gutes Produkt aus
- Keine PM-Tools verwenden: Wenn Nutzerfeedback, Erkenntnisse, Daten, Spezifikationen und Roadmaps in separaten PM-Tools eingeschlossen sind, wird der Zugang zum Produktkontext für das ganze Team erschwert
- Produktentwicklung ist ihrem Wesen nach schwer vorherzusagen, und wichtiger als das Ausliefern an sich ist es, das Richtige auszuliefern, das geschäftliche Wirkung entfaltet
- In großen produktorientierten Unternehmen sind PMs sehr wichtig, aber die benötigte Zahl an PMs wird leicht überschätzt; mehr PMs bedeuten nicht automatisch mehr Produktfokus
1 Kommentare
Hacker-News-Kommentare
Als Engineering-Manager oder Leiter einer Funktionsorganisation habe ich ziemlich lange mit Produktmanagern zusammengearbeitet und in einem mittelgroßen Tech-Unternehmen auch einmal vorübergehend die Rolle eines PM für interne Produkte übernommen.
Produktmanagement gehört meiner Ansicht nach zu den wichtigsten Bereichen dessen, was ein Unternehmen tut. Aber die Arbeit ist wirklich schwierig, und je schwächer ein PM ist, desto eher entfernt er sich davon und driftet in Mikromanagement oder interne Politik ab, unter dem Vorwand, das Engineering-Team zu „führen“.
In Organisationen, in denen Engineering und Produkt getrennte Führungslinien haben, ist dieses Problem schwer anzugehen, und selbst wenn man es nach oben eskaliert, ist die dortige Bandbreite naturgemäß sehr begrenzt. Aus Sicht eines EM machen solche PMs den besten Engineers häufig das Leben schwer, und am Ende führt das oft dazu, dass sie gehen.
Im Moment halte ich es für die beste Lösung, in jedes Team einen PM in Form eines mini-CEO zu setzen und ihn, wenn er technisch nicht stark genug ist, mit einem mini-CTO zu paaren. So gibt es deutlich weniger Raum für Politik und viel mehr Raum für Teamarbeit.
Die erfolgreichsten Teams, in denen ich war, hatten keine dedizierte Produktrolle, und alle Entscheidungen wurden von den Entwicklern getroffen.
Ich denke inzwischen, am besten ist es, nichttechnische Leute oder auch nur halbwegs technische Leute den Entwicklern aus dem Weg zu räumen, damit diese in Ruhe bauen können.
Was ich sehe, sind Menschen, die ihre Optionen vertreten und dafür Unterstützung gewinnen wollen. Diese Politik, über die sich Leute beschweren, habe ich nie gesehen. Vielleicht hatte ich einfach Glück.
Bedeutet Politik jemanden, der technisch falsch liegt, aber überzeugender argumentiert? Was ist „Politik“? Oder bin ich einfach noch nicht auf einer ausreichend hohen Ebene, obwohl ich senior principal bin?
Viele Leute, die diesen Artikel und dieses Thema analysieren wollen, übersehen einen zentralen Faktor: Anreize.
Viele Entwickler begeistern sich stärker für die Technik selbst, also fürs Coden, fürs Lösen komplexer technischer Probleme und fürs Finden effizienter Lösungen. Auch formale Belohnungen wie Beförderungen, Boni oder Anerkennung sind oft an technische Leistungen gekoppelt.
Wenn ein Entwickler 40 Stunden in Kundenrecherche steckt, wird das möglicherweise nicht so formell anerkannt oder belohnt wie eine technische Leistung, etwa die Entwicklung einer neuen Authentifizierungslösung, die dem gesamten Team hilft.
Diese Dynamik zu verändern gelingt nicht, indem man Entwickler einfach dazu anhält, mehr Zeit für Produktmanagement aufzuwenden. Es braucht einen systemischen Wandel darin, was die Organisation wertschätzt und wie sie belohnt.
Eine Umstellung der Anreizstruktur von technikzentriert auf nutzerzentriert hätte große Auswirkungen auf die Rolle des mittleren und oberen Managements. Eine solche Veränderung erschüttert die Grundlage ihrer Rollen und Verantwortlichkeiten und kann zu Verlust von Kontrolle und Einfluss führen.
Deshalb ist es sehr wahrscheinlich, dass solche Veränderungen auf subtilen, aber starken Widerstand des mittleren und oberen Managements stoßen. Diese Gruppen verfügen innerhalb der Organisation oft über beträchtliche politische Macht und Besitzstände.
Jedes handwerkliche Arbeiten lernt man in dem Moment, in dem es die Wirklichkeit berührt. Ein Filmregisseur kann seinen Film im Schneideraum tausendmal sehen, aber das eine erste Mal mit einem echten Publikum bringt ihm mehr bei als diese tausend Stunden.
Ein Schreiner kann die ganze Woche Möbel bauen und damit zufrieden sein, aber der wahre Moment kommt erst, wenn das Möbelstück im Zimmer des Kunden steht. Bei Software ist es genauso.
Wenn man möchte, dass sich Software-Ingenieure um Nutzer kümmern, müssen sie direktes Feedback dazu bekommen, was gut funktioniert und was miserabel ist, und wenn möglich sollten sie es mit eigenen Augen sehen.
Jeder ordentliche Software-Ingenieur hat einen gewissen Stolz darauf, seine Arbeit gut zu machen. Wenn dieser Stolz nur mit Code, Commit-Historien oder anderen abstrakten Konzepten verbunden ist und überhaupt nicht damit, wie gut die Software für reale Nutzer funktioniert, wie sollte dann überhaupt Interesse daran entstehen?
Fast unabhängig vom Artikel, aber dieser aktuelle Trend, AI-Bilder als Titelbild für Blogposts zu verwenden, macht mich wirklich wahnsinnig.
Wenn einem beim Schreiben kein klares Titelbild einfällt, dann muss man dafür nicht meine Bandbreite verschwenden, indem man den Fiebertraum eines Computers herunterlädt.
Ich halte AI-Bilder für ein sehr wertvolles Werkzeug und bin grundsätzlich dafür. Aber wenn man ein AI-Bild als einziges Bild auf der Seite verwendet, sollte es dafür wirklich einen guten Grund geben und nicht bloß darum, leeren Raum zu füllen.
Besonders dann, wenn man es nicht einmal geschafft hat, die Anzahl der Finger aller Personen im generierten Bild ordentlich zu kuratieren.
Das Bild soll ein bestimmtes Gefühl vermitteln. Es soll die abstrakten Konzepte des Artikels etwas greifbarer machen.
Früher habe ich im Internet nach einem Bild gesucht, das diesen Zweck erfüllt. Jetzt kann ich es direkt mit DALL-E erzeugen, und meistens ist es deutlich besser.
Das Bild soll den Artikel ergänzen. So wie der Text des Artikels Informationen, Stimmungen und Konzepte vermitteln will, sollte auch das Bild einen Teil davon übernehmen.
Niemand will Bilder sehen, auf denen Menschen aus allen großen ethnischen Gruppen im Kreis stehen und sich mit diesem Uncanny-Valley-Lächeln seltsam angrinsen.
Dieser Trend zu bizarren, seelenlosen Corporate-Illustrationen begann schon lange bevor AI-Generierung explosionsartig populär wurde.
Vermutlich liegt dahinter irgendein Glaube an Suchmaschinenoptimierung.
Gleichzeitig müssen sie einfach nur gut aussehen.
Aber daran ist auch etwas Komisches: Das Blog-Template verlangt einen Bildbereich, also füllt man ihn gedankenlos irgendwie. Wenn das zu schwierig ist, sucht man ein fades Stockfoto, und wenn selbst das zu schwierig ist, generiert man absichtlich ein fades Stockfoto.
AI-Müll ohne Inspiration und ohne Geschmack wird bald wohl alles überziehen.
Die meisten Probleme von PMs bestehen darin, dass sie nicht vor Ort unterwegs sind und die eigentliche Arbeit nicht machen. Ein guter PM muss die Lücke zwischen Engineering und Nutzern ständig überbrücken.
Diese Feedback-Schleife muss immer wiederholt werden.
Aber die meisten glauben, sie könnten nur in der Welt der Dokumente arbeiten, produzieren Roadmap-Dokumente am Fließband und versuchen mit endlosen Check-ins und Nörgeleien, die Stakeholder abgestimmt zu halten. Am Ende machen sie eigentlich die Arbeit eines „Projektmanagers“.
Das Sammeln von Anforderungen, der Umgang mit verärgerten Nutzern wegen Bugs, wöchentliche Statusmeetings und sogar das Überbringen schlechter Nachrichten zu Prioritäten – für alles wurden Senior-Entwickler oder Tech Leads vorgeschickt. Er ließ auch die meisten Agile-Rituale aus, weil er angeblich beschäftigt war. Er hat nie ein JIRA-Ticket geschrieben oder angepasst und sagte, das sei Sache der Tech-Organisation. Bei zwei anderen Tech-Teams hat er PM genauso gemacht.
Die Tech Leads und Senior-Entwickler wussten schon in der ersten Woche, dass dieser PM schlecht war, aber er hielt länger durch als wir alle und ging erst vier Jahre später im Zuge von Stellenabbau.
Management, das dem Agile-Kult verfallen ist, lässt sich leicht von solchen Leuten blenden, und sie können eine Organisation über Jahre aus der Spur bringen. Theoretisch sind die Stakeholder eines PMs die Nutzer, in der Praxis poliert man aber oft nur das Ego der Führungsebene, die einen eingestellt hat.
Zwischen Top-Management, Agile-Beratern und PMs kann eine sich selbst verstärkende Rückkopplungsschleife entstehen.
In beiden Fällen sind es nicht wettbewerbsfähige Produkte, die meist einfach weiterexistieren, bis sie irgendwann eingestellt werden. Trotzdem stellen Unternehmen PMs und POs ein und bauen irgendeine Scrum-ähnliche Struktur auf, als würden sie revolutionäre Produkte entwickeln – inklusive Dringlichkeit und Ergebnisdruck.
In solchen Umgebungen hatten PMs und POs meiner Erfahrung nach oft kaum echtes Interesse an einem guten oder auch nur brauchbaren Produkt und konzentrierten sich stattdessen auf Politik für den internen Aufstieg.
Selbst wenn sie ein zersplittertes Produkt erzeugen, das bei Features und Verbesserungen wie ein Random Walk wirkt, treiben sie das Projekt in eine Richtung, mit der sie vor Management oder Kunden gut dastehen.
Ich bin nicht alt genug, um zu wissen, wie in den 60ern, 70ern oder 80ern entwickelt wurde, aber ich vermute, dass es SCRUM/PM/PO damals nicht gab. Der pessimistische Diskurs, dass die Produktivität im Vergleich zu früheren Jahrzehnten deutlich nachgelassen hat und wir heute meist von dem leben, was früher gebaut wurde, passt ziemlich gut zu meiner Wahrnehmung.
In letzter Zeit mentoriere ich andere PMs. Es gibt zwar Roadmaps, die breit geteilt werden, aber es werden auch unglaublich viele Dokumente und Tabellen erstellt, die außer mir niemand je wieder ansieht. Es fühlt sich oft so an, als würden sie nur erstellt, um zu zeigen, dass man arbeitet, und ich versuche, diese Gewohnheit aufzubrechen.
Ich plädiere so stark für technisches Produktmanagement, weil das Problem vereinfacht betrachtet darin liegt, dass manche PMs auf einer zu hohen Abstraktionsebene feststecken. Sie können nicht täglich mit dem Team über technische Details sprechen und landen deshalb in einer seltsamen Grauzone zwischen Projektmanagement und Produktmanagement.
Das an sich ist okay, aber wenn dann noch das HIPPO-Syndrom dazukommt und Leute Produktentscheidungen treffen wollen, verbringt man die meiste Zeit damit, sich abzusichern und nach oben zu managen.
PMs bekommen viel Prügel ab, manchmal zu Recht, aber am Ende müssen sie oft interne Politik machen, damit überhaupt etwas vorangeht.
Großartige PMs entwerfen nicht nur Vision oder Plan, sondern treiben auch Umsetzung und Iteration. Planung sind nur 20% des Ganzen.
Die besten Produktmanager, mit denen ich gearbeitet habe, waren einfach außergewöhnlich fähige Leute, die die Komplexität der Umsetzung verstanden und es bei Bedarf wahrscheinlich sogar selbst hätten machen können, zugleich aber auch die geschäftlichen Anforderungen verstanden.
Sie waren Menschen, die dem Unternehmen Wert hinzugefügt haben, ohne Engineering Manager zu sein.
Leider sitzen die meisten Produktmanager einfach nur auf diesem Posten. Sie sind Gatekeeper, die sich entweder die Lorbeeren oder die Verantwortung holen, während für sie selbst oft kaum etwas auf dem Spiel steht.
Insgesamt finde ich: Wenn es eine eigene Produktmanagement-Organisation gibt, dann läuft etwas falsch.
Die besten und erfolgreichsten Produkte, an denen ich beteiligt war, gehörten immer den Leuten, die sie tatsächlich umgesetzt haben – also Menschen wie Ingenieure, Designer oder Customer-Success-Teams.
Als Ingenieur war ich gern in der Support-Rotation, weil das die Abstraktionslücke zwischen meiner Arbeit und den echten Menschen geschlossen hat, die sie jede Sekunde nutzen.
In sehr seltenen Fällen habe ich auch mit PMs gearbeitet, die wirklich einen positiven Nettowert beigetragen haben, und in all diesen Fällen wären diese Leute wahrscheinlich auch ordentliche Ingenieure geworden.
Der Hauptgrund ist: Wenn ein PM oder die Person im Team, die diese Rolle übernimmt, in dieselbe Engineering-Management-Struktur berichtet, kippt am Ende alles in Richtung der Bedürfnisse des Engineering.
Selbst dringend nötige Feature-Arbeit, die das Geschäft wahrscheinlich voranbringen würde, wird am Ende depriorisiert, weil technische Schulden oder Infrastrukturarbeit die Leute angeblich immer irgendwie blockieren. Manchmal ist das tatsächlich die richtige Entscheidung, aber um solche Entscheidungen gut zu treffen, braucht es die Spannung zwischen zwei Organisationen auf Augenhöhe. Wenn PM Teil des Engineering ist, funktioniert das nicht gut.
Natürlich ist die traurige Realität unserer Branche, dass eine separate PM-Organisation oft mehr Macht bekommt als die Engineering-Organisation, weil sie angeblich „das Gute fürs Business“ verantwortet. Wenn dann noch PMs dazukommen, die zwar Prozesse und Frameworks befolgen können, aber ihr Produkt oder ihre Nutzer nicht wirklich verstehen, wird es zum Albtraum.
Ich denke in Verhältnissen
Wie ist das Verhältnis von Frontend- zu Backend-Entwicklern? Von Engineering-Managern zu Individual Contributors? Von technischen Redakteuren zu allen Ingenieuren? Von Produktmanagern zu allen Ingenieuren?
Und ich versuche, dieses Verhältnis fein abzustimmen, um den Einfluss zu maximieren und Einmischung sowie Mikromanagement zu minimieren
Die konkreten Zahlen dieses Verhältnisses unterscheiden sich zwar von Organisation zu Organisation, aber wenn Einmischung spürbar wird oder das „Wie“ nicht ausreichend von den Ingenieuren selbst kommt, muss das Verhältnis geändert werden
Man muss die Zahl der Ingenieure pro People Manager oder Produktmanager erhöhen, damit diese sich nicht auf diese Weise einmischen können, ihre Beteiligung priorisieren müssen, sich aus den Mikrobereichen zurückziehen und den Ingenieuren die Autonomie über das Wie zurückgeben
Dasselbe gilt für QA, Junior Engineers, Senior Engineers, Architekten, HR-Personal, Vizepräsidenten und Vertriebsleute
Ich mache seit über 20 Jahren Produktmanagement und stimme dem meiste hier Gesagten zu. Verhältnisse sind wichtig
Für einen CPO ist es leicht, mit einer Armee von PMs ein Imperium aufzubauen. Dann befindet sich die Organisation in einem Zustand, in dem PMs kleine Teile der Customer Experience besitzen, etwa eine einzelne Seite, Klickraten auf Buttons optimieren, aber nicht sinnvoll zur Produktstrategie oder Vision beitragen
Es ist schwer, Produktmanager zu sein, ohne das Produkt zu besitzen
PMs sollten sich viel stärker auf Geschäftsziele konzentrieren, als es heute meist der Fall ist. Nutzerprobleme zu lösen ist notwendig, aber nicht ausreichend. Diese Problemlösung muss auch in Wert für das Unternehmen münden
Damit das möglich ist, braucht es Engineering- und UX-Partner mit starkem Produktgespür
Noch schlimmer ist es, wenn die „leicht ersetzbaren“ Entwickler von Outsourcing-Firmen kommen. Dann muss die Entwicklung durch noch mehr Management-Schichten vom Kunden abgeschirmt werden
Eine großartige Methode, das BIP zu steigern
Wenn man zum Beispiel mit ERP, Oracle Fusion Apps, WorkDay oder SAP arbeitet, kann ein einzelner PM nicht das gesamte Produkt besitzen. Stattdessen verantwortet er mehrere Features, und jedes dieser Features ist für sich komplex; bei ERP gehört typischerweise auch die Integration mit vielen anderen Produkten dazu
Trotzdem stimme ich der grundsätzlichen Richtung zu, dass ein PM etwas Bedeutendes besitzen sollte
Als Entwickler und Development Manager waren die besten Produktmanager, mit denen ich gearbeitet habe, fast nie am „Wie“ beteiligt
Natürlich konnten sie Tickets auf Epic-Ebene für den Backlog erstellen, aber darunter vertrauten sie darauf, dass du und die für das Projekt Verantwortlichen die Arbeit erledigen könnt
Das Problem ist, dass die Organisation das unterstützen muss. In den meisten Unternehmen bekommt nicht die visionäre oder wachstumsorientierte Arbeit die meiste Aufmerksamkeit, sondern die lauteste
Und solche Dinge stehen oft in direktem Konflikt mit der Richtung, die Produktverantwortliche oder Manager einschlagen wollen
PMs, die das „Wie“ nicht verstehen, also nicht wissen, wie ihr Produkt funktioniert, sind die schlimmsten
Die besten PMs, mit denen ich gearbeitet habe, hatten einen technischen Hintergrund
Wenn Leute in die Zuständigkeitsbereiche anderer treten wollen, endet das immer in einem Desaster. In beide Richtungen. Ingenieure denken zu stark aus der Perspektive des „Wie?“ und sind deshalb schlecht beim „Warum?“ und „Was?“, und Produktmanager sollten sich ebenfalls aus dem „Wie?“ heraushalten, außer wenn es darum geht, das „Was?“ oder „Warum?“ zu klären
Es muss ein Gleichgewicht geben. PMs/POs brauchen auch ein grundlegendes Verständnis. Es sollten nicht Leute sein, die kaum einen Computer bedienen können
Selbst gute PMs können ziemlich ausgebremst werden, wenn um sie herum zu viele mittelmäßige PMs sind
Ich habe mit mehreren Fortune-500-Unternehmen gearbeitet und viel kaputte Kultur gesehen
Dort lösen PMs die meisten Probleme mit dem einzigen Werkzeug, das sie haben: Meetings. Die Beförderungsanreize sind so gesetzt, dass man umso wichtiger wirkt, je größer das Meeting ist
Ich war in funktionsübergreifenden Team-Meetings mit Hunderten von Stunden Gesamtaufwand, in denen tatsächlich nur 1 bis 2 Personen gearbeitet haben; meist hat der PM die ganze Zeit geredet, während 10 bis 20 Leute stummgeschaltet waren und am Ende nur zustimmten, um zu beweisen, dass sie überhaupt da waren
Das Ergebnis ist, dass Engineering-Teams demotiviert werden, keine Zeit mehr für echte technische Arbeit haben und ohne Code-Recherche oder echtes Verständnis direkt im Meeting zu Schätzungen oder Zusagen gedrängt werden
Ich habe auch erlebt, dass PMs technische Entwürfe ablehnten, weil ihnen die Zahlen oder „Punkte“ nicht gefielen, und Ingenieure dieselbe Idee in andere „Tickets“ umformatieren mussten, nur um einer unbekannten PM-Ästhetik zu genügen
Wegen mangelnden Verständnisses und bedeutungslosem Statusgehabe wurden ganze Projekte verzögert und aus der Bahn geworfen
Umgekehrt habe ich auch mit hervorragenden PMs gearbeitet, und diese Leute haben das Team vor genau diesem Unsinn geschützt und auf die richtigen Ziele fokussiert. Solche Leute sind wertvoll, und die zuerst beschriebenen entsprechend schädlich
Das ist unabhängig von der Anzahl der PMs eher eine Geschichte darüber, mit welcher Art von PM ich gern zusammenarbeite
Ich habe in der Branche bei vier Unternehmen gearbeitet und Erfahrungen von Startups mit weniger als 40 Mitarbeitenden bis hin zu JP Morgan Chase gesammelt
Ich lehne die Vorstellung ab, dass „technische“ Menschen klüger seien als „nichttechnische“. Tatsächlich verliere ich mich als Ingenieur oft in Details und verliere das große Ganze aus dem Blick, und ich brauche häufig einen PM, der mich da wieder herausholt
Nach meiner Erfahrung sind für mich als Ingenieur die PMs am einfachsten in der Zusammenarbeit, die wenigstens ein bisschen echten Kontakt mit Code hatten
Es muss nichts Großes sein. Es reicht, wenn jemand vor langer Zeit einmal eine Website mit HTML und CSS gebaut hat, eine Ad-hoc-SQL-Abfrage geschrieben hat oder im Masterstudium einen Python-Kurs belegt hat
Es braucht einfach irgendetwas, das einem PM vermittelt, dass das Schreiben von Code weder exakte Wissenschaft noch reine Magie ist
Solche PMs setzen sich für die Ingenieur:innen ein, mit denen sie zusammenarbeiten, oder versuchen zumindest, ein Gleichgewicht zwischen Business-Anforderungen und der Realität des Engineerings herzustellen
PMs, die ganz ohne technischen Bezug PM geworden sind, neigen eher zu einer stärkeren „Business-Orientierung“. Zu bestimmten Zeitpunkten kann genau das für das Business nötig sein, aber eben nicht immer. Als Ingenieur möchte ich lieber mit jemandem arbeiten, der auch meine Perspektive besser versteht
Überhaupt nicht verbittert :p