Ich kann mich noch genau erinnern, als wenn es gestern gewesen wäre: Ein Bewerbungsgespräch für eine Position im technischen Produktmanagement für eine digitale Anwendung. Das Projekt klang zunächst interessant: Digital, skalierbar, ein klarer Use Case, ein Umfeld, in dem gutes Produktmanagement echten Mehrwert liefert.
Dann kam der Moment, der für mich alles verändert hat.
Der technische Schock
Die Anwendung – die bereits Monate oder sogar Jahre Entwicklung hinter sich hat – wurde nicht nach einem gängigen Architekturpattern wie MVC aufgebaut, sondern komplett hardgecoded. Keine Trennung von Logik, Darstellung, Daten. Keine Struktur. Keine Skalierbarkeit. Kein professionelles Fundament.
Für mich als Risiko-Managerin ist das technische Problem selbst noch das geringste. Man kann ein Produkt refactoren. Man kann Systeme neu strukturieren.
Aber genau hier endet die Ebene der reinen Technik – und beginnt die Ebene der Organisation, Kultur und der versteckten Risiken, die viel größer sind.
Das eigentliche Problem liegt tiefer: Niemand hat es gesehen?
Diese Anwendung wurde über eine lange Zeit entwickelt. Monate, vielleicht Jahre. Und niemand hat gemerkt, dass die Architektur völlig falsch läuft?
Im Gespräch wurde schnell klar: Es lag nicht nur ein Fehler vor – es lag eine systemische Blindheit vor.
Genau das war spürbar:
- Die Gesprächsatmosphäre war schambeladen.
- Die Verantwortlichen wirkten unwohl, fast defensiv.
- Man sprach nur vorsichtig darüber, wie es dazu kommen konnte.
Das löste bei mir unweigerlich Fragen aus:
- Wer war Produktmanager?
- Welche Aufgaben hat er oder sie erfüllt?
- Wie oft wurden Stakeholder eingebunden?
- Wie häufig wurde getestet – und mit welchem Ergebnis?
- Gab es ein MVP?
- Wenn ja – wie konnte man eine fehlende Architektur übersehen?
Alleine diese Fragen offenbaren, dass etwas nicht gestimmt haben kann – weder in der Führung noch im Entwicklungsprozess.
Kein agiles Setting. Kein Review. Kein Feedback.
Das größte Alarmsignal: In einem echten agilen Setup wäre das nie passiert.
Nach spätestens zwei Sprints wäre sichtbar gewesen:
- Die Codebasis ist unwartbar.
- Die Architektur widerspricht jeder Best Practice.
- Änderungen verursachen ein Risiko.
- Technische Schulden explodieren.
Es hätte sofort ein Red Flag gegeben – und zwar nicht von Einzelpersonen, sondern vom Prozess selbst. Scrum, Kanban, XP – egal welches Framework: Regelmäßige Reviews decken genau solche Fehlentwicklungen auf.
Dass das hier nicht passiert ist, spricht Bände:
- Kein echtes Produktmanagement
- Keine agilen Routinen
- Keine Qualitätssicherung
- Kein Ownership
- Kein Risikobewusstsein
Wer hat die Anwendung gebaut?
Meine persönliche Einschätzung – basierend auf Erfahrung:
Entweder hat es überhaupt keinen Produktmanager gegeben und/oder es wurde billig ausgelagert, vielleicht sogar an unerfahrene Entwickler oder Praktikanten.
Das würde erklären:
- Warum niemand Kontrollinstanzen implementiert hat
- Warum keine Architekturentscheidung dokumentiert wurde
- Warum Stakeholder Überraschungen erleben
- Warum so viel Scham im Raum stand
Und es erklärt insbesondere das hier:
Man hat auf „billig“ gesetzt – und damit das teuerste Ergebnis produziert.
Für mich war klar – und dieser Moment war entscheidend für meine Karriere
Wenn ein Unternehmen…
- kein Produktmanagement hat,
- kein agiles Setting lebt,
- Entscheidungen kaschiert statt zu kommunizieren,
- Fehler lieber verschweigt als analysiert,
- und jetzt still versucht, einen massiven Architekturfehler zu reparieren,
…dann ist klar, was als Nächstes passiert:
Der neue Produktmanager wird der Sündenbock. Wenn Köpfe rollen, ist es meistens der, der „neu“ ist und den Schaden „offiziell“ übernehmen soll. Die Verantwortlichen wollen sich hier offensichtlich absichern und es ist sehr wahrscheinlich, dass sie das tun, weil die Wahrheit entweder kürzlich aufgedeckt wurde oder bereits kurz davor steht, aufgedeckt zu werden.
In so einem Fall solltest du dir gut überlegen, ob du diesen Job im Sinne deiner Karriere wirklich annehmen willst. Ich persönlich rate davon ab. Nicht die Technik ist das Problem, sondern das gesamte System dahinter. Und genau dieses System kann dir sehr wahrscheinlich die Karriere kosten.
Weitere spannende Artikel:
- Warum toxische Unternehmenskultur deine Karriere langfristig sabotiert
- Die 7 größten Fehler im Produktmanagement – und wie sie deine Karriere gefährden
- Wie du in Bewerbungsgesprächen erkennst, ob ein Job ein versteckter Karriere-Risiko-Fall ist
FAQs – Häufige Fragen rund um Karriere, Produktmanagement & toxische Projekte
1. Kann ein einzelnes Projekt wirklich meine Karriere gefährden?
Ja. Wenn du in ein chaotisches oder toxisches Projekt gesetzt wirst, kann das schnell deinen Ruf schädigen – selbst wenn du keine Schuld trägst.
2. Woran erkenne ich im Bewerbungsgespräch, dass ein Unternehmen meine Karriere gefährden könnte?
Achte auf Scham, Ausweichmanöver, fehlende Klarheit, hektische Rechtfertigungen oder widersprüchliche Aussagen.
3. Ist Hardcoding wirklich ein Karriere-Problem?
Ja – weil es ein Symptom für fehlende Prozesse, fehlende Seniorität und schlechte Führung ist. Genau das sind Karriere-Killer.
Mein Fazit
Die technische Fehlarchitektur ist in solchen Settings nicht das wahre Problem. Sie ist lediglich der Symptomträger.
Das eigentliche Problem ist:
- eine Kultur der Vermeidung,
- fehlende Verantwortlichkeit,
- unprofessionelle Produktentwicklung
- und der Versuch, Fehler unter den Teppich zu kehren.
Für mich war klar: Meine Karriere hätte hier massiven Schaden nehmen können. Hier wurde ein Sündenbock gesucht, der im Zweifelsfall geopfert werden sollte für das System. Wenig schmeichelhaft, nicht wahr?
