Inhaltsverzeichnis

“We know our success will be largely affected by our ability to attract and retain a motivated employee base, each of whom must think like, and therefore must actually be, an owner.”

Mit diesen Worten unterstrich Jeff Bezos bereits 1997 in seinem ersten Aktionärsbrief die Bedeutung der Eigentümermentalität. Eine Aussage, die er bis heute wiederholt und die erfolgreiche Technologieunternehmen verinnerlicht haben.

Aber was bedeutet es eigentlich, wie ein Eigentümer zu denken? Marty Cagan beschreibt in “Empowered” den fundamentalen Unterschied zwischen einer Eigentümer- und einer Angestelltenmentalität: Während Angestellte sich oft auf ihre Aktivitäten konzentrieren, fokussieren sich Eigentümer auf Ergebnisse.

1. Über Produktmanagement hinaus

Während Cagan primär über Produktmanager spricht, gilt diese Mentalität gleichermaßen für Entwickler. Als Entwickler sind wir nicht nur Ausführende von Anforderungen, sondern Mitgestalter des Produkts. Wenn wir wie Eigentümer denken, verändern sich unsere Perspektive und unser Handeln fundamental:

1.1 Verantwortung für Outcomes

Statt uns nur auf die technische Implementierung zu konzentrieren, denken wir darüber nach, welchen Wert unsere Arbeit für den Kunden schafft.

1.2 Proaktives Problemlösen

Wir warten nicht auf Anweisungen, sondern identifizieren selbst Probleme und entwickeln Lösungen.

1.3 Ganzheitliches Denken

Wir verstehen das größere Bild und wie unsere Arbeit zum Unternehmenserfolg beiträgt.

1.4 Qualitätsbewusstsein

Technische Schulden werden nicht als “somebody else’s problem” betrachtet, sondern als eigene Verantwortung.

2. Die Herausforderung der Umsetzung

Die Entwicklung einer Eigentümermentalität ist keine einfache Aufgabe. Sie erfordert ein Umdenken auf beiden Seiten: Unternehmen müssen ihren Mitarbeitern echte Verantwortung und Gestaltungsspielräume geben, während Mitarbeiter bereit sein müssen, diese Verantwortung auch zu übernehmen.

Interessanterweise zeigt sich hier eine direkte Verbindung zu meinem letzten Artikel über Staffing: Die Auswahl der richtigen Mitarbeiter ist entscheidend. Nicht jeder ist bereit oder in der Lage, diese Art von Verantwortung zu übernehmen. Wie Cagan bemerkt, ist die häufigste Ablehnung von Entwicklern und Designern gegenüber einem Wechsel ins Produktmanagement die Unwilligkeit, diese umfassende Verantwortung zu tragen.

3. Der Weg zur Eigentümermentalität

Die Entwicklung einer Eigentümermentalität ist ein kontinuierlicher Prozess, der sowohl persönliches Engagement als auch die richtige Unternehmenskultur erfordert. Der Weg dorthin führt über verschiedene Entwicklungsstufen, die jeder Entwickler und Produktmanager durchlaufen sollte.

3.1 Das Business verstehen

Das Fundament der Eigentümermentalität liegt im tiefen Verständnis des Geschäfts. Dies bedeutet nicht nur, die technischen Aspekte zu beherrschen, sondern auch die wirtschaftlichen Zusammenhänge zu durchdringen. Erfolgreiche Entwickler nehmen aktiv an Strategie-Meetings teil, auch wenn sie nicht explizit eingeladen sind. Sie interessieren sich für Geschäftsberichte, verstehen die Wettbewerbssituation und kennen die Bedürfnisse verschiedener Kundensegmente. Dieses Wissen ermöglicht es ihnen, technische Entscheidungen im größeren Kontext zu treffen.

3.2 Beziehungen aufbauen

Eine Eigentümermentalität entwickelt sich nicht im Vakuum. Sie entsteht durch aktive Zusammenarbeit und den Aufbau starker Beziehungen über Abteilungsgrenzen hinweg. Der regelmäßige Austausch mit Produktmanagern, Designern und anderen Stakeholdern erweitert den Horizont und schafft ein Netzwerk, das für fundierte Entscheidungen unerlässlich ist. Besonders wertvoll sind dabei informelle Gespräche und der Austausch von Perspektiven in cross-funktionalen Teams.

3.3 Lösungsorientiertes Denken entwickeln

Eigentümer fokussieren sich auf Lösungen, nicht auf Probleme. Dies bedeutet, bei Herausforderungen nicht in Hindernissen zu denken, sondern in Möglichkeiten. Statt sich auf technische Limitationen zu konzentrieren, gilt es, kreative Wege zu finden, um Geschäftsziele zu erreichen. Dabei ist es wichtig, verschiedene Optionen abzuwägen und sowohl kurzfristige als auch langfristige Konsequenzen zu berücksichtigen.

3.4 Proaktive Initiative

Eigentümermentalität zeigt sich besonders in proaktivem Handeln. Statt auf Anweisungen zu warten, identifizieren echte Eigentümer Verbesserungspotenziale und ergreifen Initiative. Dies kann die Entwicklung von Proof of Concepts für innovative Ideen umfassen oder das frühzeitige Ansprechen von technischen Schulden. Wichtig ist dabei, nicht nur Probleme zu erkennen, sondern auch durchdachte Lösungsvorschläge zu präsentieren.

3.5 Ergebnisorientierung

Der vielleicht wichtigste Aspekt der Eigentümermentalität ist der Fokus auf messbare Ergebnisse. Nicht die Menge des geschriebenen Codes oder die Anzahl der Features zählt, sondern der tatsächliche Wert für den Kunden und das Unternehmen. Dies erfordert ein tiefes Verständnis für relevante Metriken und die Fähigkeit, den Impact der eigenen Arbeit zu messen und zu optimieren.

3.6 Langfristiges Denken

Echte Eigentümer denken nicht in Quartalen, sondern in Jahren. Sie treffen Architekturentscheidungen nicht nur basierend auf aktuellen Anforderungen, sondern berücksichtigen zukünftige Skalierbarkeit und Wartbarkeit. Dies bedeutet auch, in automatisierte Tests und CI/CD zu investieren, auch wenn der unmittelbare Nutzen nicht sofort sichtbar ist.

Die Entwicklung einer Eigentümermentalität ist kein linearer Prozess. Es gibt Rückschläge und Lernkurven. Nicht jeder Vorschlag wird umgesetzt, nicht jede Initiative ist erfolgreich. Entscheidend ist die grundsätzliche Bereitschaft, Verantwortung zu übernehmen und aus Erfahrungen zu lernen.

4. Fazit

Die Eigentümermentalität ist kein Nice-to-have, sondern eine Notwendigkeit in modernen Technologieunternehmen. Sie unterscheidet erfolgreiche von mittelmäßigen Teams und ist gleichermaßen wichtig für Produktmanager wie für Entwickler.

Bezos’ Worte von 1997 sind heute aktueller denn je. In einer Zeit, in der Technologie immer komplexer und die Märkte immer dynamischer werden, brauchen wir Menschen, die Verantwortung übernehmen und wie Eigentümer denken — unabhängig von ihrer konkreten Rolle.

Die Herausforderung für Unternehmen besteht darin, eine Kultur zu schaffen, die diese Mentalität fördert und belohnt. Für uns als Entwickler liegt die Herausforderung darin, über unsere technische Komfortzone hinauszuwachsen und echte Verantwortung für den Produkterfolg zu übernehmen.

Denn letztendlich geht es nicht darum, ob wir formal Eigentümer sind, sondern ob wir wie Eigentümer denken und handeln. Oder wie Marty Cagan es ausdrückt:

Es geht um die Verantwortung für Outcomes, nicht nur für Aktivitäten.

5. Die Realität der “Umsetzungsmentalität”

In unserem Unternehmen haben wir eine klare Trennung: Business Analysts im Team und Fachexperten ausserhalb des Teams treffen die fachlichen Entscheidungen, stimmen diese mit UX und Legal ab und schreiben die User Stories. Wir als Entwickler sind am Ende dieser Kette hauptsächlich für die technische Umsetzung zuständig.

Diese Struktur mag auf den ersten Blick effizient erscheinen — jeder macht das, wofür er ausgebildet wurde. Doch sie verhindert genau das, was Marty Cagan als entscheidend für erfolgreiche Produktentwicklung beschreibt: eine echte Eigentümermentalität im Entwicklungsteam.

Wenn wir erst eingebunden werden, nachdem alle wichtigen Entscheidungen bereits getroffen wurden, werden wir zwangsläufig zu reinen Ausführenden degradiert. Unsere (technische) Expertise und unser unvoreingenommener Blick von außen — die oft innovative Lösungswege oder kritische Einschränkungen aufzeigen könnten — bleiben bei der initialen Konzeptphase ungenutzt. Stattdessen stehen wir oft vor fertigen Anforderungen, die wir bestenfalls noch marginal anpassen können.

Diese Trennung führt zu mehreren problematischen Effekten: Erstens verlieren wir als Entwickler die Verbindung zum eigentlichen Geschäftsproblem. Wir sehen nur noch die technischen Anforderungen, nicht aber den größeren Kontext. Zweitens werden potenzielle Innovationen im Keim erstickt, weil technische Möglichkeiten nicht von Anfang an in die Lösungsfindung einfließen. Und drittens entwickelt sich eine “Wir gegen die”-Mentalität, bei der sich Entwickler als reine Dienstleister sehen, nicht als gleichberechtigte Partner in der Produktentwicklung.

Besonders frustrierend ist zu beobachten, wie agile Prinzipien nur auf dem Papier existieren. Statt mit einem MVP zu starten und durch kontinuierliches User-Feedback zu lernen, werden bestehende Produkte einfach komplett neu aufgesetzt — mit allen Features von Anfang an. Eine echte Evaluation, welche Funktionen den Nutzern tatsächlich einen Mehrwert bringen, findet nicht statt. Wenn diese umfangreichen Anforderungen dann einmal mit allen Stakeholdern abgestimmt sind, ist eine Kurskorrektur kaum noch möglich. Dies führt zu einer Art gelernter Hilflosigkeit im Entwicklungsteam: Warum noch über schlanke, iterative Lösungen nachdenken, wenn ohnehin der gesamte Funktionsumfang auf einmal umgesetzt werden muss?

Der Vergleich mit Cagans Beschreibung erfolgreicher Produktteams zeigt, wie weit wir von echter Eigentümermentalität entfernt sind. Statt als Team gemeinsam Probleme zu lösen und dabei technische und fachliche Expertise von Anfang an zu vereinen, arbeiten wir in einer Art Wasserfall-Light: Fachexperten definieren, UX designed, und wir setzen um.

Der Weg zu einer echten Eigentümermentalität würde bedeuten, diese Strukturen grundlegend zu überdenken. Entwickler müssten von Anfang an in die Problemdefinition und Lösungsfindung eingebunden werden. Business Analysts sollten als Brückenbauer zwischen Fachexperten und Entwicklung agieren, nicht als Gatekeeper. Und vor allem müsste die Organisation verstehen, dass die besten Lösungen dort entstehen, wo technische Möglichkeiten und fachliche Anforderungen von Beginn an zusammengedacht werden.

Bis dahin bleibt uns nur, im Rahmen unserer Möglichkeiten eine Eigentümermentalität zu entwickeln: durch proaktives Nachfragen nach dem Business-Kontext, durch das Einbringen alternativer Lösungsvorschläge, wo möglich, und durch den Versuch, über den reinen Umsetzungsaspekt hinauszudenken. Auch wenn das System dies nicht explizit fördert — die Verantwortung für exzellente Produkte liegt letztlich bei jedem Einzelnen von uns.