Dev-Org-Assessment als Investment-Instrument

Der Report, den niemand liest

Das Muster kennt jeder, der mit Portfolio-Unternehmen arbeitet. Nach der Akquisition beauftragt das Board eine Technical Due Diligence. Ein Beratungshaus schickt ein Team, führt Interviews, kartiert die Architektur, produziert einen 200-Seiten-Report. Honorar kassiert, Team abgezogen. Der Report landet im Shared Drive. Sechs Monate später liefert die Dev-Organisation immer noch nicht, was der Business Plan voraussetzt.

Die Diagnose war nie das Problem. Das Problem ist, dass niemand bleibt, um die Probleme zu lösen.

Wir arbeiten mit PE- und VC-Firmen, deren Portfolio-Unternehmen Engineering-Execution-Probleme haben. Keine Marktprobleme. Keine Produktprobleme. Die Investitionsthese war solide, der Kundenstamm wächst, aber die Dev-Organisation kann nicht liefern, was der Business Plan annimmt. Features brauchen Monate statt Wochen. Der CTO sagt, er brauche mehr Leute. Die Teamgröße ist bereits um 40 Prozent gestiegen, die Velocity hat sich nicht verändert. Technische Schulden wachsen schneller als das Team sie abbauen kann.

Das ist das Muster, das den Anruf auslöst.

Warum klassische Due Diligence zu kurz greift

Klassische Technical Due Diligence beantwortet die falsche Frage. Sie fragt: „Wie ist der aktuelle Stand der Technologie?” Nützlich ist das für etwa zwei Wochen. Die eigentliche Frage lautet: „Kann diese Dev-Organisation liefern, was die Investitionsthese erfordert, und wenn nicht, was tun wir dagegen?”

Ein Report kann den zweiten Teil nicht beantworten. Ein Report beschreibt. Er repariert nichts.

Das Handoff-Modell ist die Ursache. Eine Firma diagnostiziert, eine andere soll reparieren. Oder schlimmer: Die Diagnose wird dem bestehenden Management übergeben, also demselben Management, das die Probleme verursacht hat. Der CTO, der dem Board gesagt hat „wir brauchen mehr Leute”, soll jetzt Empfehlungen umsetzen, die das Gegenteil sagen.

Jeder PE/VC-Professional, mit dem wir sprechen, hat diesen Zyklus erlebt. Bewerten, empfehlen, übergeben, warten, erneut bewerten. Das Portfolio-Unternehmen verbrennt zwei weitere Quartale. Das Board stellt dieselben Fragen. Niemand kann erklären, warum die Delivery-Metriken im Operating Review immer noch flach sind.

Assessment als Investment-Instrument

Wir denken Dev-Org-Assessment anders: als erste Phase eines Verbesserungsengagements, nicht als einmaliges Audit.

Wenn wir die Technologie-Fähigkeit eines Portfolio-Unternehmens bewerten, schreiben wir keinen Report für ein Shared Drive. Wir bauen die Roadmap, die wir selbst umsetzen werden. Dasselbe Team. Dasselbe Engagement. Kein Handoff.

Das verändert, wie das Assessment aussieht. Wir stellen keine abstrakten Fragen über „Engineering Maturity”. Wir stellen spezifische: Wo staut sich die Arbeit? Warum dauert der Release-Zyklus sechs Wochen, wenn die Architektur wöchentliche Deploys hergeben würde? Was ist die tatsächliche Cycle Time von Commit zu Production? Wer trifft technische Entscheidungen, und wie schnell werden diese Entscheidungen zu Ergebnissen?

Das sind operationale Fragen. Sie haben operationale Antworten. Und diese Antworten werden zu messbaren Zielen für das Verbesserungsengagement, das direkt anschließt.

Was „sechs Monate” wirklich bedeutet

Wenn ein CTO dem Board sagt „wir brauchen sechs Monate, um das zu beheben”, heißt das meistens: Er braucht sechs Monate Spielraum, um Dinge auszuprobieren, ohne definierte Ziele und ohne externe Prüfung, ob der Ansatz funktioniert.

Wir arbeiten in 100-Tage-Zyklen mit Zielen, die vor Tag eins vereinbart werden. Alle zwei Wochen bekommt der Investment Partner einen Fortschrittsbericht mit echten Zahlen: Zykluszeit, Durchsatz, Deployment-Frequenz, Fehlerraten. Keine Erzählung darüber, was sich für das Team „besser anfühlt”. Nach 100 Tagen wird gemessen: Ziele erreicht oder nicht? Wenn es mehr zu tun gibt, definieren wir neue Ziele für den nächsten Zyklus. Wenn die Arbeit erledigt ist, führen wir den geplanten Exit durch.

Das 100-Tage-Modell ist für PE/VC gebaut:

Strukturierter Zyklus. Definierte Ziele, messbare Ergebnisse, klarer Zeitrahmen. Kein offenes Beratungsmandat, das leise zur dauerhaften Kostenstelle wird.

Geplanter Exit. Keine dauerhafte Abhängigkeit. Wenn wir gehen, gehört dem Team des Portfolio-Unternehmens alles, was wir gebaut und jedes Verfahren, das wir geändert haben. Keine proprietären Frameworks. Keine Lizenzgebühren. Kein „ihr braucht uns, um das zu warten”.

Wiederholbar. Dasselbe Modell funktioniert über das gesamte Portfolio. Wir haben mehrere Engagements für dieselbe Investmentfirma durchgeführt: verschiedene Portfolio-Unternehmen, verschiedene technische Herausforderungen, dieselbe Engagement-Struktur, jeweils angepasst.

Die Rolle des Technology Operating Partners

PE/VC-Firmen haben Operating Partners für Commercial Strategy, für Finance, für Go-to-Market. Die Technologie-Seite wird oft vernachlässigt oder von einem Board-Mitglied abgedeckt, das vor zwanzig Jahren CTO war und starke Meinungen zu Programmiersprachen hat, aber keine aktuelle operative Erfahrung.

Wir arbeiten als Technology Operating Partner. Hands-on, eingebettet im Portfolio-Unternehmen. Nicht beratend. Keine „strategischen Empfehlungen” per quartalsweisem Slide Deck. Wir arbeiten im Engineering-Team, messen, was geliefert wird, finden die Engpässe und beheben sie.

Das ist kein Staffing-Modell. Wir parken keine Köpfe in Ihrem Portfolio-Unternehmen. Wir bringen Senior-Spezialisten mit einer definierten Mission, führen den Verbesserungszyklus durch, transferieren das Wissen und gehen. Das Ziel ist immer dasselbe: die Dev-Organisation unabhängig handlungsfähig machen, dann raus.

Vom Assessment zum messbaren Ergebnis

Bei DataCollect, einem Portfolio-Unternehmen, das Edge-AI-Fähigkeiten für sein Verkehrsmonitoring-System brauchte, identifizierte das Assessment, dass die Erkennungsgenauigkeit bei 50 Prozent feststeckte. Dasselbe Team, das das Problem identifiziert hatte, baute die Lösung: optimierte Erkennungsmodelle auf Produktions-Hardware und eine neu aufgebaute Deployment-Pipeline. Die Erkennungsgenauigkeit stieg auf 95 Prozent. Aus „wir können das nicht” wurde ein wettbewerbsfähiges Produkt im KI-basierten Verkehrsmonitoring.

Kein Slide Deck hat das bewirkt. Das Assessment identifizierte die Lücke. Das Verbesserungsengagement schloss sie. Dasselbe Team, dasselbe Engagement, messbares Ergebnis.