Vom Entwickler zum CTO

Als Entwickler war mein Tag einfach zu bewerten: Habe ich heute etwas gebaut, das gestern noch nicht existierte? Als CTO in einem Startup funktioniert dieser Maßstab nicht mehr – und es hat eine Weile gedauert, bis ich verstanden habe, warum sich das nicht wie Verlust anfühlen muss.

Der Code ist nicht mehr das Produkt

Die erste und härteste Umstellung: Als Entwickler ist der Code das Produkt. Als CTO ist er nur noch eine von mehreren Zutaten. Daneben stehen plötzlich Fragen wie: Bauen wir überhaupt das Richtige? Können wir uns diese Architekturentscheidung in zwölf Monaten noch leisten? Was muss heute gut sein, was darf vorerst hässlich bleiben?

Die letzte Frage ist die wichtigste. Im Studium und in den ersten Berufsjahren lernt man, Dinge richtig zu bauen. Im Startup lernt man, dass „richtig“ ein Budget hat. Die eigentliche Ingenieursleistung ist nicht der saubere Code – es ist die Entscheidung, wo Sauberkeit gerade ihren Preis wert ist und wo nicht.

Entscheiden ohne vollständige Information

Als Entwickler konnte ich Entscheidungen fast immer absichern: Tests schreiben, Prototyp bauen, Benchmark laufen lassen. Als CTO sind die wichtigsten Entscheidungen genau die, für die es diese Absicherung nicht gibt. Welches Modell, welcher Anbieter, welche Abstraktionsebene – oft mit Informationen, die in sechs Monaten veraltet sind.

Was mir dabei hilft, ist eine einfache Frage: Wie teuer ist es, diese Entscheidung später zu korrigieren? Reversible Entscheidungen dürfen schnell und unvollständig informiert fallen. Nur die wirklich schwer korrigierbaren – Datenmodell, Kernarchitektur, Verträge – verdienen langes Nachdenken. Das meiste, worüber man lange diskutieren könnte, gehört in die erste Kategorie.

Loslassen, ohne den Anschluss zu verlieren

Der Punkt, vor dem sich vermutlich jeder technische Gründer fürchtet: der Moment, in dem man nicht mehr jede Zeile kennt. Er kommt früher, als man denkt, und er ist gesund – ein CTO, der jeden Pull Request selbst schreiben will, ist ein Engpass mit Jobtitel.

Aber Loslassen heißt nicht Abwenden. Ich versuche, an zwei Stellen nah am Code zu bleiben: bei allem, was Architektur langfristig festlegt, und bei allem, was unser Kernrisiko berührt – bei uns die Verlässlichkeit der KI-gestützten Simulation. Der Rest ist Vertrauen, klare Schnittstellen und die Bereitschaft, Lösungen zu akzeptieren, die anders sind als meine gewesen wären. Manchmal besser.

Was bleibt

Die Sorge, als CTO das Handwerk zu verlieren, hat sich für mich nicht bestätigt – das technische Urteilsvermögen wird sogar wichtiger, nur die Einsatzstelle verschiebt sich. Statt selbst die Lösung zu bauen, muss ich schnell erkennen, ob eine vorgeschlagene Lösung trägt, wo sie brechen wird und welche Frage noch niemand gestellt hat.

Wenn ich es auf einen Satz verdichten müsste: Als Entwickler wird man daran gemessen, was man baut. Als CTO daran, was das Team baut – und woran es nicht arbeitet.