Stakeholder-Interviews

HealthTech Solutions GmbH

Meilenstein 1: Forensische Diagnose PB-0802: Stakeholder-Interviews planen und durchführen | April 2026

---

Einleitung

Wir haben mit relevanten Stakeholdern der HealthTech Solutions gesprochen, um verschiedene Perspektiven auf die Situation des Unternehmens zu erhalten. Ziel war es, Widerstände, Schmerzpunkte und verdeckte Konflikte zu identifizieren, die über das offizielle Narrativ hinausgehen. Die Interviews wurden als halbstrukturierte Gespräche geführt, um Raum für spontane Einsichten zu lassen.

Befragte Stakeholder:

Methodik: Halbstrukturierte Einzelinterviews mit offenen Leitfragen. Dauer zwischen 38 und 55 Minuten. Interviewnotizen enthalten zusätzliche Beobachtungen zur Körpersprache und Gesprächsdynamik, um nonverbale Signale als diagnostische Indikatoren zu nutzen.

---

Interview 1: Maximilian Meier – Gründer & CEO

[Beobachtung: Meier erscheint pünktlich, aber sichtlich erschöpft. Sein Telefon vibriert während des Gesprächs mehrfach – er schaut jedes Mal kurz drauf. Redet schnell, springt zwischen Themen, unterbricht sich selbst häufig.]

Frage: Herr Meier, wie würden Sie die aktuelle Situation bei HealthTech Solutions beschreiben?

Wir sind in einer – ich nenne es mal – Wachstumskrise. Das klingt paradox, ich weiß. Wir haben in zwei Jahren von zehn auf 250 Leute skaliert, unser Produkt rettet wortwörtlich Leben, die Investoren sind happy. Aber intern? Intern fühlt es sich an, als würde ich ein Flugzeug im Flug umbauen. Jeden Tag.

[Beobachtung: Meier greift zum Wasserglas und trinkt hastig. Er wirkt, als hätte er diesen Satz schon oft gedacht, aber selten ausgesprochen.]

Frage: Was genau meinen Sie mit Wachstumskrise?

Schauen Sie – als wir zu zehnt waren, wusste jeder alles. Kevin, unsere CTO-Seite, ich, wir saßen nebeneinander, haben Entscheidungen in fünf Minuten getroffen. Jetzt? Jetzt sitze ich in Meetings, in denen mir Leute erklären, was in ihrem Team passiert, und ich denke mir: Das hätte ich vor einem Jahr in zwei Minuten am Whiteboard gelöst. Aber ich kann nicht mehr alles selbst machen. Oder – nein, eigentlich: Ich versuche es trotzdem, und genau das ist das Problem.

Frage: Sie sind sich also bewusst, dass Ihr persönliches Involvement ein Engpass sein könnte?

Bewusst? Ja, rational schon. Aber emotional? Wissen Sie, dieses Produkt ist mein Baby. Unsere KI erkennt Krebstumore früher als jeder Radiologe. Wenn da ein Fehler im Algorithmus ist, steht am Ende ein Mensch, der eine falsche Diagnose bekommt. Da kann ich nicht einfach loslassen und sagen: „Macht mal." Ich MUSS das kontrollieren.

[Beobachtung: Seine Stimme wird merklich lauter bei diesem Punkt. Hier liegt eine tiefe emotionale Bindung, die über normales Gründer-Ego hinausgeht – eine genuine Angst vor medizinischen Konsequenzen, die als Rechtfertigung für Mikromanagement dient.]

Frage: Wie erleben Sie die Zusammenarbeit zwischen den drei Gründern aktuell?

Kevin und ich – das funktioniert, weil wir uns seit dem Studium kennen. Wir streiten, aber produktiv. Das Problem ist eher: Wir sind uns oft ZU einig, und dann überrollen wir den Rest. Ich merke das manchmal in den Gesichtern der Teamleiter. Die nicken, aber ich spüre, dass sie eigentlich anderer Meinung sind. Nur sagt keiner was. Das beunruhigt mich.

Frage: 25 Prozent Fluktuation – wie erklären Sie sich das?

(Lange Pause) Das ist die Zahl, die mich nachts wach hält. Wir verlieren gute Leute. Richtig gute Leute. Die gehen zu Google, zu Siemens Healthineers, weil die ihnen – und das ist das Bittere – „Struktur" bieten. Wir bieten Freiheit, Mission, Impact. Aber anscheinend reicht das nicht mehr, wenn du morgens nicht weißt, woran du nachmittags arbeitest.

[Beobachtung: Meier reibt sich die Schläfen. Hier wird sichtbar: Der CEO ist sich der Symptome bewusst, verbindet sie aber nicht mit dem systemischen Muster – nämlich, dass die fehlende Struktur direkt aus dem Gründer-Flaschenhals resultiert.]

Frage: Und die regulatorischen Herausforderungen?

Das Gesundheitsamt ist – mit Verlaub – eine Katastrophe für uns. Die wollen saubere Prozessdokumentation, Audit-Trails, Verantwortlichkeitsmatrizen. Alles berechtigt, verstehen Sie mich nicht falsch. Aber wir haben halt keine. Wir haben nie welche gebraucht. Und jetzt stehen wir da und müssen in sechs Monaten etwas nachweisen, wofür andere Firmen Jahre brauchen. Das macht mir ehrlich gesagt am meisten Angst.

Frage: Wenn Sie eine Sache sofort ändern könnten – was wäre das?

(Denkt lange nach) Ich würde mir selbst beibringen, loszulassen. Klingt einfach, ist das Schwerste, was ich je machen müsste. Ich bin Physiker, ich bin Kontrollmensch. Aber HealthTech ist größer als ich. Das muss ich akzeptieren. Theoretisch.

[Beobachtung: Das „Theoretisch" am Ende ist entlarvend. Meier hat die richtige Erkenntnis, aber die Umsetzung scheitert am Identätskonflikt: Gründer-Identität vs. CEO-Rolle in einem skalierten Unternehmen.]

---

Interview 2: Kevin Karnewitz – Gründer & CDO

[Beobachtung: Karnewitz kommt sieben Minuten zu spät, entschuldigt sich mit einem „Sorry, Code-Review lief über." Er wirkt ruhiger als Meier, analytischer, aber mit einer spürbaren Frustration unter der Oberfläche. Spricht in langen, präzisen Sätzen.]

Frage: Herr Karnewitz, Sie sind CDO. Was genau umfasst Ihre Rolle aktuell?

Offiziell bin ich für die gesamte Daten- und KI-Strategie verantwortlich. Inoffiziell? Inoffiziell bin ich Senior Code Reviewer, Architektur-Entscheider, Eskalationsinstanz für technische Streitfragen und manchmal auch derjenige, der nachts um zwei Hotfixes einspielt. Meine Rolle ist – sagen wir – nicht ganz so abgegrenzt, wie sie sein sollte.

Frage: Sie sind also tief in der operativen Arbeit?

Zu tief. Ich weiß das. Aber hier ist das Dilemma: Unser Codebase ist historisch gewachsen. Keine Architektur-Dokumentation, keine ADRs, kein technisches Radar. Das Wissen über kritische Systemteile sitzt in vielleicht fünf Köpfen. Meiner ist einer davon. Wenn ich mich rausziehe, gibt es niemanden, der bestimmte Entscheidungen treffen kann. Nicht weil die Leute dumm sind – sondern weil das System so gebaut ist, dass es mich braucht.

[Beobachtung: Karnewitz beschreibt ein klassisches Bus-Factor-Problem mit bemerkenswerter Klarheit. Im Gegensatz zu Meier reflektiert er das System, nicht nur seine eigene Rolle – aber handelt trotzdem nicht anders.]

Frage: Wie würden Sie die technischen Schulden einschätzen?

Auf einer Skala von eins bis zehn? Acht. Vielleicht neun. Wir haben in der Frühphase – verständlicherweise – Shortcuts genommen. Proof of Concept, der plötzlich Produktionscode wurde. Module, die „temporär" zusammengesteckt wurden und jetzt das Fundament bilden. Wir hatten letzten Monat drei System-Ausfälle in zwei Wochen. Drei. Bei einer Krebserkennungs-Software. Ich schlafe schlecht deswegen.

Frage: Wird das in der Organisation thematisiert?

Thematisiert? Alle wissen es. Aber priorisiert? Nein. Weil Max – und ich verstehe ihn da – unter dem Druck der Investoren steht, Features zu liefern. Jedes Quartal gibt es ein Investor-Update, und da muss die Feature-Liste länger sein als letztes Mal. Technical Debt ist kein Bullet Point, der Investoren begeistert. Also schieben wir es. Und schieben es. Und schieben es.

[Beobachtung: Hier wird die Dynamik zwischen Geschäftsdruck und technischer Realität sichtbar. Karnewitz fungiert als stiller Mittler zwischen Meiers Feature-Druck und der technischen Wahrheit.]

Frage: Neue Entwickler brauchen angeblich sechs Monate Einarbeitungszeit. Stimmt das?

Sechs Monate ist optimistisch. Für die Kernmodule – die Bilderkennungs-Pipeline, das Scoring-Modell – ist es eher neun. Wir haben kein Onboarding, keine Wikis, keine Pair-Programming-Kultur. Neue Leute werden ins kalte Wasser geworfen und müssen sich durchfragen. Und die einzigen, die wirklich Antworten haben, sind überlastet. Es ist ein Teufelskreis.

Frage: Wie erleben Sie die Situation mit den regulatorischen Anforderungen?

Das ist der Punkt, der mich am meisten beschäftigt. Aus Ingenieurssicht sind die Anforderungen des Gesundheitsamts absolut sinnvoll. Traceability, Validierung, Dokumentation – das sind keine Bürokratie-Monster, das sind Qualitätsmerkmale, die wir eigentlich sowieso hätten haben sollen. Aber jetzt müssen wir das im Nachhinein einziehen, in ein System, das dafür nicht gebaut wurde. Das ist, als würden Sie in ein fahrendes Auto nachträglich Sicherheitsgurte einbauen.

Frage: Was bräuchte HealthTech Ihrer Meinung nach am dringendsten?

Drei Dinge: Erstens, eine echte Architektur-Vision mit dokumentierten Entscheidungen. Zweitens, ein Team – ich nenne es mal „Plattform-Team" – das sich ausschließlich um die technische Infrastruktur kümmert und den Feature-Teams den Rücken freihält. Drittens – und das wird Max nicht gerne hören – müssen wir aufhören, jede technische Entscheidung durch uns drei Gründer zu schleusen. Wir brauchen technische Leads, die autonom entscheiden dürfen.

[Beobachtung: Karnewitz ist der reflektierteste der Stakeholder. Er benennt Lösungsrichtungen, die exakt auf Team Topologies und dezentrale Governance einzahlen. Gleichzeitig hat er es in zwei Jahren nicht geschafft, diese Einsichten durchzusetzen – was auf ein Machtungleichgewicht zu Meiers Gunsten hindeutet.]

---

Interview 3: Dirk Manchow – Teamleiter & Product Owner

[Beobachtung: Manchow ist der Älteste im Team und strahlt eine ruhige Professionalität aus, die in starkem Kontrast zum hektischen Umfeld steht. Er wählt seine Worte sorgfältig, fast diplomatisch. Man spürt: Dieser Mann hat schon viele Organisationen gesehen – und weiß, was hier schiefgeht.]

Frage: Herr Manchow, Sie sind als Teamleiter und Product Owner in einer Doppelrolle. Wie funktioniert das?

Kurze Antwort: gar nicht. Lange Antwort: Ich bin Product Owner für unser Radiology-Team und gleichzeitig disziplinarischer Teamleiter für acht Entwickler. Das bedeutet, ich priorisiere das Backlog, führe Sprint Reviews, mache aber auch Mitarbeitergespräche, kümmere mich um Urlaubsanträge und Konflikte. Das sind zwei Vollzeitjobs in einer Person. Ich komme zu nichts richtig.

Frage: Wie würden Sie die Priorisierung im Unternehmen beschreiben?

(Seufzt hörbar) Chaotisch. Und ich sage das als jemand, der Chaos gewohnt ist. Bei Siemens gab es zu viel Prozess – hier gibt es zu wenig. Ich plane am Montag den Sprint, und am Dienstag kommt eine Slack-Nachricht von Max: „Dirk, Investor XY will Feature Z sehen, könnt ihr das diese Woche noch reinquetschen?" Und dann werfe ich meinen Plan um. Jede Woche. Mein Team hat kein Vertrauen mehr in unsere Planung, weil sie wissen, dass sie nichts wert ist.

[Beobachtung: Manchow stellt sein Wasserglas ab und verschränkt die Arme – klassische Abwehrhaltung. Dieses Thema ist emotional aufgeladen.]

Frage: Was macht das mit Ihrem Team?

Es macht die Leute müde. Und zynisch. Wir haben angefangen, intern von „Priority of the Day" zu sprechen – POTD, wie ein Running Gag. Das klingt lustig, ist aber toxisch. Weil es bedeutet, dass niemand mehr an langfristige Ziele glaubt. Die Leute arbeiten von Feuerwehreinsatz zu Feuerwehreinsatz. Und die Besten – die, die strategisch denken können – gehen als Erste, weil sie das nicht aushalten.

Frage: Sie kommen von Siemens Healthineers. Was war Ihre Motivation, zu HealthTech zu wechseln?

Die Mission. Ehrlich. Ich habe bei Siemens in einem regulären MedTech-Umfeld gearbeitet und wusste: KI wird dieses Feld revolutionären. Aber bei Siemens dauert alles zehn Jahre. HealthTech hatte diesen Spirit: schnell, mutig, technologisch brillant. Und das Produkt ist wirklich gut – besser als vieles, was ich bei Siemens gesehen habe. Aber „gutes Produkt" und „gute Organisation" sind zwei verschiedene Dinge.

Frage: Was vermissen Sie am meisten?

Klarheit. Bei Siemens wusste ich genau: Wer entscheidet was. Wer ist verantwortlich für was. Hier? Hier entscheidet im Zweifelsfall Max, egal ob es sein Bereich ist oder nicht. Oder Kevin nickt etwas ab im Code Review, und plötzlich ist das die Architekturentscheidung für die nächsten zwei Jahre – ohne dass das jemals diskutiert wurde.

Frage: Wie ist die psychologische Sicherheit in Ihrem Team?

Niedriger als sie sein sollte. Die Leute trauen sich nicht, „Nein" zu sagen. Nicht wegen Angst vor Bestrafung – so ist es nicht. Sondern weil die Mission so groß ist, dass sich jeder schlecht fühlt, der bremst. Wer sagt „Das schaffen wir nicht in dem Tempo", fühlt sich wie ein Verräter an der Sache. Das ist subtiler Druck, kein offener. Aber er wirkt.

[Beobachtung: Manchow benennt ein Kernproblem: Mission-Drift als Instrument der informellen Kontrolle. Die Vision des Unternehmens wird unbewusst als Druckmittel genutzt, um Widersprüche zu unterdrücken.]

Frage: Was würden Sie einer externen Beratung empfehlen, als Erstes anzugehen?

Die Entscheidungsrechte klären. Punkt. Wer darf was entscheiden, ohne dass es durch die Gründer muss? Solange das nicht klar ist, ist alles andere Kosmetik. Sie können die schönsten Frameworks einführen – wenn Max am Ende trotzdem per Slack-Nachricht alles über den Haufen wirft, bringt das nichts.

[Beobachtung: Manchow ist der strategischste Denker unter den Interviewten. Seine Erfahrung aus einem strukturierten Konzern gibt ihm die Vergleichsfolie, die den anderen fehlt. Seine Frustration ist kontrolliert, aber spürbar tief.]

---

Interview 4: Claudette März – Entwicklerin

[Beobachtung: März ist direkt und unverblümt. Sie kommt mit Laptop und hat sich offensichtlich vorbereitet – öffnet zwischendurch Slack-Nachrichten als „Beweismaterial". Ihre Körpersprache: vorgebeugt, energisch, leicht genervt. Sie will gehört werden.]

Frage: Frau März, wie erleben Sie Ihren Arbeitsalltag bei HealthTech?

Wie ein ständiger Sprint. Und ich meine das nicht im agilen Sinne – ich meine: Dauerhaft rennen, nie ankommen. Wir haben theoretisch Zwei-Wochen-Sprints, aber die Realität ist: Am dritten Tag kommt was Neues rein, am fünften Tag ändert sich die Prio, und am Ende des Sprints haben wir halb angefangene Sachen, die nie fertig werden. Das ist frustrierend. Extrem frustrierend.

Frage: Was passiert mit der Code-Qualität unter diesem Druck?

Die leidet. Massiv. Ich schreibe Code, von dem ich weiß, dass er technisch Schulden aufbaut. Aber ich habe keine Wahl, weil das Feature gestern hätte fertig sein sollen. Wir haben Stellen im System – ich zeige Ihnen das – (zeigt Bildschirm), wo eine Änderung in Modul A dazu führt, dass Modul C in Produktion crasht. Und niemand versteht warum, weil es keine Doku gibt und der Einzige, der Modul C gebaut hat, vor acht Monaten gekündigt hat.

[Beobachtung: März zeigt eine Slack-Konversation, in der ein Kollege schreibt: „Bitte nicht anfassen, das hat Björn gebaut und Björn ist weg." – ein Paradebeispiel für Wissensmonopole und fehlende Dokumentation.]

Frage: Sie sind seit drei Jahren da. Wie hat sich die Kultur verändert?

Als ich angefangen habe, waren wir 40 Leute. Das war wild, aber schön. Jeder kannte jeden, wir haben zusammen Pizza gegessen und nachts gehackt. Das war echte Startup-Energie. Jetzt sind wir 250 und versuchen immer noch, so zu arbeiten wie damals. Aber das funktioniert halt nicht mit 250 Leuten. Die Kultur von damals ist zur Überlebensideologie geworden: „Wir sind agil, wir brauchen keinen Prozess." Doch, brauchen wir. Dringend.

Frage: Wie ist Ihr Verhältnis zu den Gründern?

Max ist charismatisch. Der kann einen Raum begeistern. Aber im Alltag? Da ist er der Chef, der um 23 Uhr Slack-Nachrichten schickt mit „Können wir mal über Feature X reden?" und damit meint: „Bau das bis morgen." Kevin ist anders – der versteht den Code, der ist technisch brillant. Aber er hat so einen Perfektionismus, dass Code Reviews manchmal Tage dauern. Und in der Zeit steht mein Branch still. Es ist ein Bottleneck, der aus guter Absicht entsteht.

[Beobachtung: März differenziert klar zwischen den Gründern und ihren jeweiligen Engpass-Mustern: Meier als strategischer Störer, Karnewitz als operativer Bottleneck.]

Frage: Was würden Sie sich wünschen?

Nummer eins: Dass jemand – irgendjemand – mal „Nein" zu einem Feature-Request sagt. Nicht alles, was ein Investor will, muss sofort gebaut werden. Nummer zwei: Dokumentation. Nicht hundert Seiten Confluence, sondern einfache ADRs – Architecture Decision Records. Damit nicht alles in Köpfen steckt, die morgen kündigen können. Nummer drei: Ein Onboarding, das den Namen verdient. Ich war letzte Woche Buddy für einen Neuen. Ich konnte ihm nichts zeigen, weil es nichts zu zeigen gibt außer „Frag Kevin".

Frage: Würden Sie bleiben, wenn sich nichts ändert?

(Lange Pause) Ich gebe HealthTech noch sechs Monate. Die Mission ist mir wichtig – Krebserkennungs-KI, das ist nicht irgendein Ad-Tech-Startup. Aber ich bin 28, ich will lernen, ich will wachsen. Und gerade lerne ich nur, wie man unter Chaos überlebt. Das ist keine Karriere, das ist Schadensbegrenzung.

[Beobachtung: März' Aussage „sechs Monate" deckt sich mit der Fluktuationsrate von 25 %. Die besten Leute setzen sich intern Deadlines. Wenn die Organisation nicht liefert, gehen sie.]

---

Interview 5: Stanislav Przijc – Entwickler

[Beobachtung: Przijc ist ruhig, fast zurückhaltend. Er wägt jedes Wort ab, bevor er spricht. Sein Blick wandert häufig aus dem Fenster – man hat den Eindruck, er überlegt bei jeder Antwort, wie viel er preisgeben kann, ohne jemandem zu schaden. Ein loyaler Mensch in einem System, das Loyalität nicht belohnt.]

Frage: Herr Przijc, Sie arbeiten im Compliance-Team. Das ist bei HealthTech relativ neu, oder?

Das Team gibt es seit acht Monaten. Und „Team" ist großzügig gesagt – wir sind drei Entwickler und ein halber Product Owner, der eigentlich noch ein anderes Team betreut. Wir wurden zusammengestellt, weil das Gesundheitsamt angeklopft hat. Also: Wir sind ein Reaktionsteam, kein strategisches. Das merkt man an allem.

Frage: Was genau ist Ihre Aufgabe?

Wir sollen die Audit-Trails nachbauen. Also: Nachvollziehbar machen, wer wann welche Änderung an den KI-Modellen vorgenommen hat, wie Trainingsdaten validiert wurden, wie Entscheidungen des Algorithmus dokumentiert sind. Das klingt einfach, ist aber ein Alptraum, weil das System nie dafür gebaut wurde. Wir versuchen, Nachvollziehbarkeit in ein System einzubauen, das aktiv dagegen arbeitet.

[Beobachtung: Przijc beschreibt eine retroaktive Compliance-Integration – ein häufiges Anti-Pattern in schnell gewachsenen Startups. Die Kosten steigen exponentiell, je später man anfängt.]

Frage: Bekommen Sie genügend Unterstützung dafür?

Nein. Und ich sage das ohne Bitterkeit, das ist einfach eine Tatsache. Die Feature-Teams haben ihre eigenen Deadlines. Wenn ich einen Entwickler von Team Radiology brauche, um mir zu erklären, wie ein bestimmtes Modul funktioniert, dann muss ich drei Tage warten, weil der in seinem Sprint steckt. Oder ich frage Kevin direkt, aber der hat auch keine Zeit. Und Max sagt: „Compliance ist wichtig, aber erstmal müssen wir Feature X für den Investor fertig haben." Es gibt eine informelle Hierarchie der Prioritäten, und Compliance steht ganz unten.

Frage: Wie gehen Sie persönlich mit dieser Situation um?

Ich dokumentiere alles, was ich kann, auch wenn niemand danach fragt. Ich habe angefangen, ein internes Wiki zu schreiben – nur für mein Team – weil ich Angst habe, dass das Wissen sonst verloren geht, wenn einer von uns geht. Das mache ich in meiner Freizeit, weil es im Sprint keine Story dafür gibt. Ist das nachhaltig? Nein. Aber jemand muss es machen.

[Beobachtung: Przijc zeigt klassisches „Hero"-Verhalten, aber in einer leisen, unauffälligen Form. Er kompensiert systemische Defizite durch persönlichen Einsatz – das typische Muster, das zu Burnout führt.]

Frage: Sie kommen aus einem FinTech mit reguliertem Umfeld. Was fällt Ihnen hier besonders auf?

Dass die Leute denken, Regulierung sei der Feind. Bei meinem alten Arbeitgeber war Regulierung Teil der DNA – wir haben mit der BaFin gearbeitet, nicht gegen sie. Hier höre ich Sätze wie „Das Gesundheitsamt will uns ausbremsen". Aber das stimmt nicht. Die wollen, dass das Produkt sicher ist. Das wollen wir doch auch, oder? Ich glaube, das Problem ist, dass Compliance hier als Strafe wahrgenommen wird, nicht als Qualitätsmerkmal.

Frage: Was bräuchten Sie, um Ihre Arbeit gut machen zu können?

Zuerst: Ein klares Mandat von oben. Nicht „Compliance ist wichtig" als Lippenbekenntnis, sondern echte Priorität. Das heißt: Entwicklerzeit, die für Compliance-Zuarbeit geblockt ist. Dann: Zugang zum Code und zu den Entscheidungsträgern, ohne jedes Mal betteln zu müssen. Und langfristig: Eine Architektur, die Compliance als Feature hat und nicht als Nachrüstung.

Frage: Sehen Sie sich langfristig bei HealthTech?

(Zögert) Ich sehe das Potenzial. Das Produkt ist wirklich beeindruckend. Und ich glaube an die Mission. Aber wenn ich ehrlich bin: Wenn in sechs Monaten immer noch alles so ist wie jetzt – wenn Compliance immer noch das Stiefkind ist und ich weiter in meiner Freizeit Doku schreibe – dann suche ich mir was anderes. Nicht weil ich nicht will, sondern weil ich nicht kann. Das frisst einen auf.

[Beobachtung: Przijc bestätigt das Muster: Auch er hat einen internen Countdown. Bemerkenswert ist die Ähnlichkeit zu März' Zeitfenster – beide geben der Organisation ungefähr sechs Monate. Dies korreliert exakt mit dem nächsten Meilenstein der regulatorischen Zulassung.]

---

Synthese: Kernwiderstände und Schmerzpunkte

Priorisierte Kernwiderstände

1. Gründer-Flaschenhals (Kritisch)

Alle fünf Stakeholder benennen – direkt oder indirekt – die Gründerabhängigkeit als zentrales Hindernis. Meier kontrolliert strategische Prioritäten per Slack-Nachricht, Karnewitz ist operativer Bottleneck durch Code-Reviews und Architekturentscheidungen. Ohne beider Zustimmung passiert nichts. Dieser Flaschenhals erzeugt Stau, Frustration und die Illusion von Agilität bei gleichzeitiger Starre.

2. Fehlende Struktur und Entscheidungsrechte (Hoch)

HealthTech hat keine definierten Entscheidungswege, keine Rollenklarheit und keine Governance. Manchow beschreibt es am prägnantesten: Alles andere ist Kosmetik, solange nicht klar ist, wer was entscheiden darf. Die „flache Hierarchie" ist in Wahrheit eine unsichtbare Hierarchie mit den Gründern an der Spitze.

3. Technische Schulden und Wissensverlust (Hoch)

Karnewitz bewertet die Technical Debt mit 8–9 von 10. März beschreibt Module, die niemand mehr anfassen darf, weil die Ersteller das Unternehmen verlassen haben. Przijc baut in seiner Freizeit Dokumentation auf. Das System ist fragil, schlecht dokumentiert und von einzelnen Wissensträgern abhängig – ein kritisches Risiko für ein Medizinprodukt.

4. Regulatorik als Kulturschock (Mittel-Hoch)

Die regulatorischen Anforderungen treffen auf eine Organisation, die Compliance als Feind betrachtet (Przijc) und keine Prozesse hat, um sie zu erfüllen. Das Compliance-Team ist unterbesetzt, hat kein Mandat und wird strukturell deprioritisiert. Die Zulassung ist gefährdet.

5. Missionsdruck als informelles Kontrollinstrument (Mittel)

Die lebensrettende Mission des Produkts wird unbewusst genutzt, um Widerspruch zu unterdrücken. Wer bremst, fühlt sich als Verräter an der Sache (Manchow). Dies führt zu sinkender psychologischer Sicherheit und verstärkt die Hero Culture, in der individuelle Aufopferung als Normalzustand gilt.

---

Schmerzpunkte-Matrix

---

Implikationen für Rich Picture und Impact Map

Rich Picture: Die informellen Machtstrukturen verlaufen sternförmig von den Gründern nach außen. Jeder Informations- und Entscheidungsfluss geht durch Meier oder Karnewitz. Manchow fungiert als informeller Puffer zwischen Gründerebene und Teams. Die Compliance-Funktion (Przijc) ist organisatorisch isoliert und hat keine Verbindung zur Entscheidungsebene.

Impact Map: Das primäre Geschäftsziel (Outcome) muss die regulatorische Zulassung sein – ohne sie existiert das Produkt nicht am Markt. Sekundär: Reduktion der Fluktuation auf unter 15 % und Halbierung der Onboarding-Zeit. Die Stakeholder-Interviews zeigen, dass alle drei Ziele denselben systemischen Hebel haben: Dezentralisierung der Entscheidungsrechte und Aufbau von Strukturkapital (Dokumentation, Prozesse, klare Rollen).

Download als PDF

Stakeholder-Interview, bitte hier klicken