Toller Job – oder versteckter Karriere-Killer?

Aktualisiert am: 26. März 2026

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:

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?

Was wie politische Strategie wirkt, ist in vielen Unternehmen längst Realität.

Entscheidungen entstehen nicht nur durch Leistung oder Logik – sondern durch Dynamiken wie Loyalität, Unsicherheit und interne Machtverhältnisse.
Genau hier passieren die größten Fehleinschätzungen – vor allem bei internen Bewerbungen, wo viele glauben, dass „gute Arbeit“ automatisch gesehen wird.
👉 Ich habe diese unsichtbaren Entscheidungsmechaniken anhand realer Praxisfälle aufbereitet – damit du erkennst, wie intern wirklich entschieden wird.

Autorin von Global Insight Group Intelligence:

Michaela Schaaf-Hoffelner verfügt über mehr als 35 Jahre Erfahrung im technischen Projektmanagement – insbesondere in den Bereichen IT, Steuerungstechnik und Intralogistik. Durch ihre langjährige Arbeit an komplexen Systemen und Transformationsprozessen erkennt sie frühzeitig strukturelle Risiken, die in klassischen Analysen oft übersehen werden.

Ihr Fokus liegt darauf, diese verborgenen Muster sichtbar zu machen – und sie in konkrete strategische Vorteile für Investoren und Entscheider zu übersetzen. Ihre Analysen verbinden technisches Systemverständnis mit geopolitischen und wirtschaftlichen Entwicklungen.