- Viele CTOs verlagern ihren Schwerpunkt auf Management, behalten aber weiterhin einen Ansatz bei, bei dem sie selbst Code schreiben und Produkte entwickeln
- Durch drei Arten von Entwicklungsarbeit – experimentelle Projekte, dringende Kundenanfragen und Bugfixes – schaffen sie einen hohen Hebel innerhalb der Organisation
- Indem sie weiter programmieren, erleben sie den tatsächlichen Nutzen und die Grenzen von AI-Tools aus erster Hand und sichern die Realitätsnähe technischer Entscheidungen
- Statt auf Management legen sie ihre Stärken und ihre Leidenschaft auf Problemlösung und Produktentwicklung und gestalten dafür die passende Organisationsstruktur
- Für die Rolle des CTO gibt es kein standardisiertes Muster; entscheidend ist, einen Führungsstil zu finden, der zu den eigenen Stärken und zur Situation des Unternehmens passt
Warum ich als CTO weiter Code schreibe
- Viele CTOs hören mit der Zeit auf zu programmieren, ich halte aber weiterhin an einem Ansatz fest, bei dem ich selbst Features entwickle und deploye
- In den vergangenen 12 Monaten habe ich mehrere wichtige Features ausgeliefert, ohne ein direkt an mich berichtendes Team zu haben
- Das ist nicht bloß ein Hobby, sondern die Rolle eines Entwicklers für Kernfunktionen, die tatsächlich im Produkt landen
- Ich betrachte das als „eine der wirkungsvollsten Aktivitäten eines technischen Leaders“
Drei Arten von Projekten, die ich tatsächlich baue
1. Langfristige experimentelle Projekte (Long-horizon experimental projects)
- In einer Organisation gibt es nur sehr wenige Personen, die tatsächlich in der Lage sind, neue Produkte zu bauen
- Die meisten Organisationen konzentrieren sich auf die Wartung und Skalierung bestehender Produkte
- Nur Gründer, einige Executives und leistungsstarke Individual Contributors (ICs) haben den Spielraum, neue Produkte auszuprobieren
- Wegen Organisationsstruktur, Roadmap-Anreizen und begrenztem Risikobudget können die meisten Engineers keine unsicheren Projekte über Monate hinweg vorantreiben
- Ein CTO ist in einer einzigartigen Position, unsichere experimentelle Projekte schnell voranzutreiben, gestützt auf ein tiefes Verständnis von Customer Pain Points und der Architektur
- Es gab Fehlschläge, aber auch große Erfolge
- Beispiel AI-Chat-Produkt: Ein Projekt, dessen Wert vom Team erkannt wurde, das aber wegen Zeitmangel immer wieder verschoben wurde, habe ich über die Thanksgiving-Feiertage als Prototyp gebaut
- Anschließend wurde es gemeinsam mit dem Team zu einem kommerzialisierten Produkt mit ARR in Millionenhöhe weiterentwickelt
2. Dringende Kundenanforderungen (Critical customer asks)
- Es gibt Situationen, in denen ein Feature, das ein wichtiger Kunde dringend braucht, zum Blocker für einen großen Vertrag oder eine Verlängerung wird
- Statt Engineers aus einem laufenden Sprint herauszuziehen, übernehme ich das als CTO selbst, auf Basis schneller Entscheidungen und eines Gesamtverständnisses des Systems
- Konkretes Beispiel: Anfrage nach einer Data-Redaction-Funktion für die Compliance eines Kunden mit einem Jahresvolumen von einer Million Dollar
- Die erste Einschätzung des Teams war, dass der Kunde entweder selbst eine API-Integration bauen oder mehrere Abstimmungsrunden zwischen Produkt, Legal und Engineering nötig wären
- Ich habe innerhalb eines Tages eine funktionierende Version gebaut und deployt und damit die Kundenbeziehung gesichert
3. Bugfixes
- Viele sind überrascht, aber Bugfixes sind eine meiner liebsten Methoden, um meine mentale Landkarte der Codebase aktuell zu halten
- Wenn ich verfolge, warum auf Seite 3 der Suchergebnisse die Pagination kaputtgeht oder warum eine WebSocket-Verbindung genau nach 60 Sekunden abbricht, durchlaufe ich das gesamte System
- So gewinne ich ein intuitives Verständnis technischer Schulden, das sich durch Code-Reviews oder Architekturgespräche nur schwer erlangen lässt
- Diese Erfahrung hilft mir, die nötige Intuition für Richtung und Priorisierung technischer Investitionen zu behalten
Warum ich weiter programmiere
1. Um zu verstehen, welche Technologie in der Praxis funktioniert
- Durch die tägliche Nutzung von AI-Tools wie Claude Code, Codex und Cursor kann ich bei Tool- und Hiring-Entscheidungen Realität von Hype unterscheiden
- Ein aktuelles Beispiel: Ich habe versucht, ein Feature mit Vibe-Coding umzusetzen, das eine komplexe Integration berührt, kam aber nicht voran; als ich es selbst von Hand schrieb, ging es deutlich schneller
- Die Code-Menge war nicht groß, aber die Logik musste präzise sein (ein Bereich, in dem LLMs schwach sind)
- Ein anderes großes Feature wiederum habe ich fast vollständig mit Claude Code entwickelt
- Zu wissen, wo AI stark ist (CRUD, Tests, Boilerplate) und wo sie scheitert (Präzision, Systemnuancen), ist besser als Entscheidungen auf Basis von Twitter-Hype
- Wenn man selbst im Code steckt, kann man spüren, wann man Druck machen und wann man nachlassen sollte
- Man erkennt, wann die Architektur zu komplex wird oder wann technische Schulden tatsächlich zum Problem werden
- Manager, die sich nur auf Reports verlassen, können vieles übersehen
2. Um mich auf das zu konzentrieren, worin ich gut bin und was mir Freude macht
- Organisationsaufbau und Personalmanagement machen mir nicht besonders viel Spaß
- Engineering-Management erfordert zwischenmenschliche Dynamiken, Leistungsbeurteilungen und Organisationsdesign
- Das sind wichtige Funktionen, aber nicht meine stärksten Bereiche
- Deshalb stelle ich exzellente Engineering Manager und Führungskräfte ein
- Sie können das besser und haben mehr Freude daran
- So kann ich mich als CTO auf Produktentwicklung, das Lösen technischer Probleme und das Programmieren konzentrieren
- Ein Startup ist wie ein „Sprint-Marathon“, daher gestalte ich meine Rolle um Arbeit, die mein Interesse aufrechterhält und mich lange schnell laufen lässt
- Das ist über Jahre hinweg nachhaltig und für das Unternehmen sehr wichtig
3. Weil AI-Tools den Hebel vergrößert haben
- Vor einigen Jahren war es schwierig, neben strategischer Arbeit noch Zeit fürs Programmieren zu finden
- Mit dem Wachstum des Unternehmens war ich den ganzen Tag in Meetings gefangen und arbeitete außerhalb meiner Stärken
- Das war eine der professionell schwierigsten Phasen
- Moderne AI-Tools haben diese Gleichung grundlegend verändert (besonders in den letzten Monaten)
- Die Produktivität ist im Vergleich zu früher um das 2- bis 3-Fache gestiegen
- Diese Tools ersetzen weder Urteilsvermögen noch technisches Wissen, sondern machen diese Fähigkeiten noch wertvoller
- Wenn ich einem AI-Tool sage: "Baue einen Datenexport, der dem bestehenden CSV-Exportformat entspricht, aber drei zusätzliche Felder aus der Benutzerprofiltabelle enthält", erzeugt es den Großteil des Codes korrekt
- Ich habe tiefen Kontext dazu, was genau gebraucht wird und wo es zu finden ist
- Ein Engineer, der mit diesem Teil der Codebase nicht vertraut ist, würde viel Zeit brauchen, um die Details zu verstehen
- Die Arbeit verschiebt sich von "jede einzelne Zeile Code schreiben" hin zu "Kontext liefern, Entscheidungen treffen und Lösungen bewerten"
- Und glücklicherweise habe ich viel Kontext
Den eigenen Weg finden
- Bei der Definition der CTO-Rolle habe ich mich an Greg Brockmans Blogpost zur Definition der CTO-Rolle bei Stripe orientiert
- Nach Gesprächen mit verschiedenen CTOs wurde mir klar, wie stark die Rolle variieren kann
- Manche CTOs sind technische Visionäre, manche Organisationsbauer, manche stark auf Infrastruktur fokussiert
- Gemeinsam ist guten CTOs, dass sie herausfinden, wo sie unter Berücksichtigung ihrer spezifischen Fähigkeiten, Interessen und der Unternehmenssituation den größten Wert schaffen können
- In meinem Fall bedeutet das, viel Code zu schreiben
- Ich baue Software lieber, als Organisationen zu entwerfen
- Mit meinem tiefen Wissen über Kunden und Codebase bin ich dabei besonders wirksam
- Ich stelle starke Engineering Manager ein
- Das ist jedoch mein persönlicher Weg, keine allgemeine Vorschrift
- Die CTO-Rolle ist sehr flexibel
- Ob Organisationsaufbau oder Produktstrategie: Technische Führung kann je nach Stärken, Energiequellen und Unternehmensbedarf sehr unterschiedlich aussehen
- An Engineers, die Sorge haben, dass Leadership den Verzicht auf technische Arbeit bedeutet: Es gibt viele Wege
- Entscheidend ist, den Bereich zu finden, in dem man auf einzigartige Weise besonders gut ist
5 Kommentare
Ich bin selbst aktiver CTO und stimme diesem Artikel überhaupt nicht zu.
Ich stimme zwar zu 100 % zu, dass man das Coden nicht aufgeben sollte, aber dafür reicht es, Open Source zu machen, das nichts mit dem Produkt des Unternehmens zu tun hat. Ich denke, diese Aussage gilt nur aus der Perspektive eines technischen Founders in einem frühen Startup, der als Allrounder arbeiten muss.
Für ihn mag das gut sein … aber was ist mit dem Unternehmen?
Man sollte eine Arbeit machen, die dem eigenen Gehalt entspricht …
Es ist schon merkwürdig, dass der CTO experimentelle Projekte selbst übernimmt. Wenn man den Mitarbeitenden in der Praxis genug Zeit gäbe, könnten sie das doch gut bewältigen. Am seltsamsten finde ich, dass langfristige experimentelle Projekte offenbar nur vom CTO durchgeführt werden sollen. Wenn er selbst die Befugnis hat, Ressourcen zu nutzen, könnte er doch eigens Ressourcen für experimentelle Projekte beschaffen und den Mitarbeitenden ausreichend Zeit geben.
Ein persönlicher Weg ... Ich muss das wohl gut managen, damit die organisatorischen Aufgaben nicht immer mehr werden.
Hacker-News-Kommentare
Wenn ich darüber nachdenken würde, bei welcher Firma ich mich bewerben soll, und einen Blogbeitrag sähe, in dem ein CTO damit prahlt, jedes Wochenende Code zu committen, würde ich mich auf die Flucht vorbereiten
Die Aufgabe einer Führungskraft ist es, eine gesunde Unternehmenskultur zu schaffen, und mit Wochenendarbeit zu prahlen ist das genaue Gegenteil
Außerdem ist es ein riskantes Signal, öffentlich zu sagen, man habe ein Kundenproblem in nur einem Tag gelöst und dabei Legal- oder Engineering-Reviews ausgelassen
In Startups in der Frühphase ist die Kultur völlig anders, und solche Texte funktionieren eher als Filter, der passende Talente aussiebt
Der Code, den ich schreibe, dient meist internen DevEx-Verbesserungen oder dem Abbau technischer Schulden
Rechtliche Prüfungen lasse ich dabei nie aus, und ich bewege mich eher auf PoC-Niveau als bei Produktionscode
Für einen Gründer-CTO ist es wichtig, nah am Code zu bleiben, aber entscheidend ist, das Gleichgewicht nicht zu verlieren
Die Rolle des CTO ist von Firma zu Firma unterschiedlich
Wie beim Stripe-Beispiel von Greg Brockman ist der eine CTO eher ein technischer Visionär, ein anderer ein Organisationsarchitekt, wieder ein anderer stärker auf Infrastruktur fokussiert
In meinem Fall programmiere ich gern und bin tief in Kunden und Codebasis eingebunden, und genau so schaffe ich den größten Mehrwert
Der Titel „CTO“ ist nur vage definiert
Manche CTOs sind Gründer und können frei coden, andere arbeiten stark kundenorientiert und verlieren irgendwann den Zugang zum Code
Andererseits gibt es auch autoritäre CTOs
Letztlich muss man klären, um welchen Typ CTO es sich handelt, damit die Frage „Warum code ich?“ überhaupt Sinn ergibt
In diesem Fall ist die Bezeichnung CTO nur eine Rollenabgrenzung
Der CTO konzentriert sich auf Strategie und Ausrichtung, der VP auf das tägliche Engineering-Management
Ob das über Organisationsaufbau oder direktes Coden geschieht, ist zweitrangig
Wenn Führungskräfte selbst Code schreiben, können Code-Reviews verzerrt werden, und das Team kann in Verwirrung geraten
Am Ende ist die Person dann möglicherweise kein CTO, sondern im Herzen weiterhin Entwickler
Ich bin nicht grundsätzlich dagegen, dass ein CTO programmiert, aber in diesem Fall wirkt es so, als werde die CTO-Rolle nicht ausreichend ausgefüllt
Die eigentliche technische Führung übernimmt ein Gründungsingenieur, nur bei deutlich geringerer Vergütung – genau das ist das Problem
Ein CTO ohne Berichtslinie, der nur codet, ist meiner Meinung nach eher in der Rolle eines Senior-Entwicklers als in der Strategie
Ich habe selbst schon solche Angebote bekommen, aber am Ende war das nur ein formaler Titel
Wenn die Organisation wächst, wird sich die Rolle wahrscheinlich verändern
In einem kleinen Startup arbeite ich mit dem Team in Sprints; wenn sich Termine verschieben, ist es meine Aufgabe, die Ursachen zu beheben und auf Leute mit Burnout zu achten
Aber wenn man dem Text nach urteilt, die Teamstruktur nicht einmal genug Luft für heiße AI-Projekte lässt, dann ist das ein Organisationsproblem
Ein CTO sollte nicht selbst coden, sondern solche systemischen Engpässe beseitigen
Die Rollen von „Senior“ oder „Head“ unterscheiden sich von Firma zu Firma komplett
Die Probleme, die entstehen, wenn sich ein CTO zu sehr ins Coden vertieft, sind klar
Verzerrte PR-Reviews, Vernachlässigung der eigentlichen Aufgaben, Rollenverwirrung und Eingriffe in die Autonomie des Teams
Die Vorstellung „Ein CTO sollte nicht coden und nur Strategie machen“ ist mechanisches Denken
Das Wesen eines Technologieunternehmens ist Wertschöpfung, und manchmal kann es die wertvollste Tätigkeit sein, wenn ein CTO selbst an einem Tag ein großes Feature implementiert
Das kann ein wesentlich produktiverer Tag sein als jede KPI-Besprechung
Manchmal ist es nötig, dass das C-Level wieder direkt ein Gefühl für die Praxis bekommt
Bei manchen ist der Grund, CTO zu sein, schlicht der, dass sie Mitgründer sind
Würde man mit diesem Ansatz in ein anderes Unternehmen gehen, käme man womöglich nicht einmal auf das Niveau eines Staff Engineers
Zum Schluss noch: Dass auf der Preis-Seite der Unternehmenswebsite keine tatsächlichen Preise stehen, kann für Verwirrung sorgen und sollte korrigiert werden