Fractional CTO: Wann externe technische Führung sinnvoll ist — und wann nicht

Viele Unternehmen haben ein Digitalisierungsvorhaben, einen Dienstleister und ein Budget — aber niemanden, der technische Entscheidungen mit Verantwortung trifft. Genau in diese Lücke fällt die Rolle des Fractional CTO. Dieser Leitfaden beschreibt nüchtern, was sie leistet, woran Sie den Bedarf erkennen und wann Sie besser etwas anderes tun.

Was ein Fractional CTO ist — und was nicht

Ein Fractional CTO übernimmt technische Führung in Teilzeit, dauerhaft angelegt und in die Organisation eingebunden. Nicht als Gast, sondern als Person, die Entscheidungen trifft, verantwortet und später erklären muss.

Die Abgrenzung zu benachbarten Rollen ist wichtig, weil sie oft verwechselt werden:

• Interim-CTO: springt Vollzeit für eine vakante Position ein, meist befristet auf sechs bis zwölf Monate. Der Fractional CTO ist kein Lückenfüller, sondern ein dauerhaftes Teilzeitmodell — häufig, weil eine Vollzeitstelle für die Unternehmensgröße schlicht nicht sinnvoll ist.
• Technologieberater: analysiert, empfiehlt und übergibt ein Dokument. Die Umsetzung bleibt beim Unternehmen. Der Fractional CTO bleibt in der Umsetzung und trägt die Konsequenzen seiner Empfehlungen mit.
• Projektleitung: steuert Termine, Aufwände und Status. Technische Führung entscheidet über Architektur, Schnitt, Qualitätsmaßstäbe und Technologiewahl — und darüber, was bewusst nicht gebaut wird.
• Entwicklungsdienstleister: liefert Umsetzung. Ein Dienstleister ohne technischen Gegenpart auf Kundenseite optimiert zwangsläufig nach seinen eigenen Maßstäben. Das ist keine Böswilligkeit, sondern Struktur.

Kurz: Der Fractional CTO ist die technische Gegenseite, die ein Unternehmen braucht, um mit Dienstleistern auf Augenhöhe zu sprechen und um eigene Systeme über Jahre tragfähig zu halten.

Fünf Signale, dass Bedarf besteht

1. Es gibt keinen technischen Gegenpart zum Dienstleister

Angebote werden angenommen, weil sie plausibel klingen, nicht weil jemand sie fachlich prüft. Change Requests werden bezahlt, ohne dass jemand beurteilen kann, ob sie berechtigt sind. Der Dienstleister ist nicht das Problem — die fehlende Gegenseite ist es.

2. Architekturentscheidungen bleiben liegen

„Das entscheiden wir später" ist eine Entscheidung. Meist die teuerste. Wenn niemand befugt ist, Datenmodell, Schnittstellen oder Betriebsmodell festzulegen, entsteht keine Architektur, sondern ein Ergebnis aus Zufällen.

3. Delivery hat keine Verantwortliche

Es gibt Termine, Tickets und Meetings, aber niemanden, der für das Gesamtergebnis geradesteht. Bei Verzögerungen fragen alle in die Runde, statt dass jemand Prioritäten neu setzt.

4. Recruiting ohne technisches Urteil

Sie stellen Entwicklerinnen und Entwickler ein, ohne beurteilen zu können, ob die Person zum Vorhaben passt. Die Folge sind teure Fehlbesetzungen und Teams, die sich fachlich nicht gegenseitig tragen.

5. Die Software ist fertig, aber sie wird nicht genutzt

Das ist das häufigste und teuerste Signal. Das System läuft, die Fachabteilung führt trotzdem weiter ihre Tabelle. Adoption scheitert selten an Funktionen, meist an fehlender Nachvollziehbarkeit, an Prozessen, die nie mitgedacht wurden, oder daran, dass niemand die Übergabe begleitet hat.

Ein einzelnes Signal ist noch kein Grund. Drei davon gleichzeitig sind einer.

Was in den ersten 90 Tagen realistisch passiert

Seriöse technische Führung liefert in den ersten Wochen kein neues System, sondern Klarheit.

Tag 1 bis 30 — Bestandsaufnahme. Gespräche mit Fachabteilungen, Dienstleistern und Team. Welche Systeme existieren, wer nutzt sie tatsächlich, wo laufen Daten doppelt, welche Verträge und Abhängigkeiten bestehen. Am Ende steht eine schriftliche, überprüfbare Lagebeschreibung — kein Foliensatz.

Tag 31 bis 60 — Entscheidungen treffen. Die drei bis fünf Fragen, die alles andere blockieren, werden benannt und beantwortet: Bauen oder kaufen. Bestandssystem ablösen oder stabilisieren. Wer betreibt was. Jede Entscheidung wird mit Begründung dokumentiert, damit sie in zwei Jahren noch nachvollziehbar ist.

Tag 61 bis 90 — Arbeitsfähigkeit herstellen. Ein belastbarer Schnitt der nächsten Ausbaustufe, klare Ownership pro Thema, definierte Qualitätsmaßstäbe, ein funktionierender Weg von der Idee bis in den Betrieb. Ab hier ist die Rolle dauerhaft und ruhiger.

Wer Ihnen in 90 Tagen eine fertige Transformation verspricht, hat entweder das Vorhaben nicht verstanden oder verkauft etwas anderes.

Einsatzmodelle und Aufwand

In der Praxis funktionieren zwei bis sechs Tage pro Monat für begleitende Führung, sechs bis zehn Tage in Phasen mit aktiver Umsetzung. Weniger als zwei Tage ist Beratung, nicht Führung. Mehr als zehn Tage wirft die Frage auf, ob nicht eine feste Anstellung sinnvoller wäre — eine ehrliche technische Führung sagt Ihnen das von sich aus.

Entscheidend ist weniger die Anzahl der Tage als die Arbeitsweise:

• Async als Standard. Entscheidungen werden schriftlich begründet, nicht in Meetings verhandelt, an denen die Hälfte der Betroffenen nicht teilnimmt. Das ist bei Teilzeit-Führung keine Präferenz, sondern Voraussetzung.
• Klare Entscheidungsbefugnis. Ohne Mandat entsteht eine teure Empfehlungsinstanz. Legen Sie von Anfang an fest, was ohne Rücksprache entschieden werden darf.
• Erreichbarkeit statt Anwesenheit. Ein fester Slot pro Woche plus definierte Reaktionszeit schlägt verteilte Anwesenheit ohne Struktur.
• Kündbarkeit. Monatlich oder quartalsweise. Ein Modell, das Sie nicht beenden können, ist kein Teilzeitmodell.

Wann es nicht passt

Ehrlichkeit gehört zur Rolle, deshalb hier die Fälle, in denen wir davon abraten:

• Sie brauchen Kapazität, keine Führung. Wenn klar ist, was zu bauen ist, und nur Hände fehlen, ist ein Entwicklungsteam die richtige Antwort.
• Technologie ist Ihr Kerngeschäft. Ein Softwareprodukt als Haupterlösquelle braucht technische Führung in Vollzeit, im Haus und langfristig.
• Die Organisation will keine Entscheidungen. Wo jede Festlegung durch fünf Gremien muss, wird auch externe Führung nichts bewegen. Das ist ein Führungsthema, kein technisches.
• Das Vorhaben ist klein und klar umrissen. Eine überschaubare Anwendung mit einem verlässlichen Dienstleister braucht keine zusätzliche Führungsebene.
• Sie suchen jemanden, der bestehende Entscheidungen bestätigt. Dann sparen Sie sich das Geld.

Woran Sie Qualität erkennen

Nehmen Sie diese Fragen ins Erstgespräch mit. Die Antworten sagen mehr als jedes Profil:

• Welche Entscheidung haben Sie in einem Projekt getroffen, die sich als falsch herausgestellt hat — und wie sind Sie damit umgegangen?
• Wann haben Sie einem Kunden zuletzt von einem Vorhaben abgeraten?
• Wie dokumentieren Sie Entscheidungen, damit sie nach Ihrem Weggang nachvollziehbar bleiben?
• Woran messen Sie in sechs Monaten, ob die Zusammenarbeit funktioniert hat?
• Wie gehen Sie vor, wenn die Fachabteilung ein fertiges System nicht nutzt?
• Was passiert am Ende der Zusammenarbeit — wie sieht die Übergabe konkret aus?

Warnzeichen: sofortige Technologieempfehlungen ohne Kenntnis Ihrer Fachlichkeit, Referenzen ohne nachvollziehbares Ergebnis, und jede Antwort, die aus Schlagworten statt aus Beispielen besteht.

Nächster Schritt

Bei KAIHITO ist Fractional Tech Leadership Teil von Software-Entwicklung & Delivery — weil Führung ohne Lieferfähigkeit selten reicht und Lieferung ohne Führung selten ankommt.

Wenn Sie unsicher sind, ob die Rolle zu Ihrem Vorhaben passt: Schreiben Sie uns. Ein erstes Gespräch dauert 30 Minuten, und wir sagen Ihnen auch, wenn etwas anderes die bessere Antwort ist.