Jeder sagte mir, ich solle aufhören.
Nicht bösartig — ehrlich gemeint, wohlwollend, mit der Art von Besorgnis, die man für jemanden reserviert, von dem man denkt, dass er seine Zeit verschwendet. „Du bist jetzt ein Gründer, Gautam. Delegiere den Code." Mein Mitgründer bei Seahawk Media sagte um 2018 etwas Ähnliches, als wir hundert aktive Kundenprojekte gleichzeitig überschritten. Die Logik war schlüssig: Gründer sollten sich um Systeme, Einstellungen und Pipeline kümmern. Nicht um Pull Requests.Seahawk Media said something similar around 2018 when we crossed a hundred active client projects simultaneously. The logic was sound: founders should think about systems, hiring, pipeline. Not pull requests.
Ich habe diesen Rat ignoriert. Und ich bin froh, dass ich das getan habe.
---
Der Moment, in dem ich fast mit dem Programmieren aufgehört hätte (und nicht)
Zurück in 2019 gab mir ein Kunde einen Brief, über den ich immer noch lachen muss. Eine mittelständische E-Commerce-Marke — ich nenne sie nicht — wollte einen kompletten WooCommerce-Rebuild, einen benutzerdefinierten Produktkonfigurator, das ganze Programm. Enger Zeitrahmen. Ich vertraute diese Aufgabe einem Entwickler im Team an, überzeugt, dass dies genau das war, wovon ich mich hätte zurückziehen sollen.
Nach drei Wochen verließ der Entwickler uns. Persönliche Gründe, völlig verständlich. Aber wir hatten einen halbfertigen Konfigurator, einen Kunden, der mir im Nacken saß, und eine Codebasis, die nur eine Person vollständig verstanden hatte.
Ich öffnete VS Code an jenem Sonntag um 7 Uhr morgens und schloss ihn erst mittags. Ich schaffte es. Nicht weil ich ein Held bin — weil ich mich tatsächlich an die Code-Muster erinnerte, die WooCommerce-Hook-Architektur, das Verhalten von woocommerce_before_add_to_cart_button, wenn man einen benutzerdefinierten Post-Typ hat, der Produktvariationen speist. Ich hatte es nicht vergessen. Ich hatte nur so getan, als wäre ich weitergezogen.woocommerce_before_add_to_cart_button behaves when you've got a custom post type feeding product variations. I hadn't forgotten. I'd just been pretending I had moved on.
Dieses Projekt hat meine Sicht auf meine Rolle völlig umgestaltet.
---
Was „Founder Who Codes" wirklich bedeutet
Es bedeutet nicht, dass ich jede Funktion baue. Das tue ich nicht. Seahawk hat Entwickler, die mir in spezifischen Dingen weit überlegen sind — Animation, komplexes React-State-Management, Datenbankoptimierung im großen Maßstab. Das ist keine falsche Bescheidenheit. Es ist wahr.
Aber Codieren als Gründer bedeutet, dass ich den Bezug zur Arbeit nie verliere. Es gibt einen Unterschied zwischen dem Management eines Projekts und dem Verständnis desselben. Wenn ein Entwickler mir sagt „das wird zwei Wochen dauern", kann ich die richtige Frage stellen — „sind das zwei Wochen, weil die API-Authentifizierung wirklich komplex ist, oder weil wir etwas neu aufbauen, das bereits in einem WordPress-Plugin existiert?"feel of the work. There's a difference between managing a project and understanding one. When a developer tells me "this will take two weeks," I can ask the right question — "is that two weeks because the API authentication is genuinely complex, or because we're rebuilding something that already exists in a WordPress plugin?"
Das kannst du nicht aus 10.000 Metern Höhe fragen. Das geht einfach nicht.
Das Schätzungsproblem
Das ist die Sache mit Software-Schätzungen: Sie sind Geschichten, die sich Entwickler selbst erzählen, genauso wie sie sie Kunden erzählen. Ich habe schon erlebt, dass ein Senior Developer vier Tage für einen Custom WordPress REST API Endpoint veranschlagt hat, der letztendlich nur sechs Stunden brauchte, nachdem ich mich mit ihm hingesetzt und das Projekt richtig gescoped hatte. Nicht, weil er faul war. Weil keiner von uns sich wirklich damit auseinandergesetzt hatte, was der Endpoint eigentlich tun musste.WordPress REST API endpoint that took six hours once I sat down with them and scoped it properly. Not because they were lazy. Because neither of us had dug into what the endpoint actually needed to do.
Je regelmäßiger du code, desto besser wird dein Gespür für unrealistische Schätzungen. Dramatisch besser.
---
Das macht mich zum besseren internen Kunden
Niemand sagt dir, wenn du eine Agentur führst: Deine Entwickler sind deine internen Kunden. Du musst sie von guten Entscheidungen überzeugen, genauso wie externe Kunden. Und du verlierst diese Fähigkeit in dem Moment, in dem du aufhörst, ihre Sprache zu sprechen.
Ich nutze Figma für Design Handoffs. Ich nutze Git (genauer gesagt GitHub – wir haben 2021 alles von Bitbucket dorthin migriert). Ich schreibe echte Tickets in Linear mit genug Details, dass ein Developer die Arbeit ohne Kickoff-Call starten kann. Letzteres allein hat uns wahrscheinlich 40 Minuten pro Projekt gespart, und wir führen viele Projekte durch.Figma for design handoffs. I use Git (specifically GitHub, we moved everything there from Bitbucket in 2021). I write actual tickets in Linear with enough specificity that a developer can start work without a kickoff call. That last one alone has saved us probably 40 minutes per project, and we run a lot of projects.
Das ist alles unmöglich, wenn du komplett „Big Picture" unterwegs bist. Du musst wissen, was ein Developer in einem Ticket braucht. Das weißt du nur, wenn du selbst auf der anderen Seite gesessen hast.
Das Code Review, das keiner vom Boss erwartet
Ab und zu hinterlasse ich einen Kommentar in einem PR. Nicht um zu micromanagen – das mache ich explizit deutlich. Aber ein Kommentar wie „dieser Filter läuft bei jedem Seitenaufruf, können wir das Ergebnis cachen?" signalisiert etwas Wichtiges: Ich achte auf die Details, die zählen.
Developer respektieren das. Manche sind überrascht davon. Und ehrlich gesagt, diejenigen, die davon genervt sind – das sagt mir auch etwas Nützliches.annoyed by it — that tells me something useful too.
---
Die Tools, die ich 2024 tatsächlich nutze
Mein Stack ist für einen Tech-Founder peinlich unsexy. VS Code mit einer Handvoll Extensions (Prettier, GitLens, PHP Intelephense). Eine lokale Entwicklungsumgebung mit LocalWP — ich bin 2020 von MAMP gewechselt und habe nie zurückgeblickt. Terminal für alles Git-bezogene, weil ich GUI nie wirklich vertraut habe.LocalWP — I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
Bei Client-Projekten greife ich immer noch zu WordPress. Wir haben auf Webflow, Shopify und Custom Laravel gebaut — aber WordPress ist dort, wo ich am schnellsten bin, und Speed zählt, wenn man immer wieder kurz reinspringt statt 8-Stunden-Sessions zu machen.
Letzten Dienstag habe ich Coolors.co genutzt, um schnell eine Brand-Palette für eine Landing Page eines Clients zu ziehen. Hat mich vier Minuten gekostet. Einen Designer zu briefen, zu warten und zu reviewen hätte eine Stunde gedauert. Das ist der Founder-Coding-Vorteil im Miniaturformat.
---
Was du tatsächlich verlierst, wenn du aufhörst
Die meisten Founder, die den Editor verlassen, reden sich ein, dass sie durch Osmose technisch bleiben. Sie werden es von Stand-ups und Slack-Threads aufnehmen. Das werden sie nicht.
Hier ist, was tatsächlich passiert:
- Dein Vokabular driftet ab. „API", „Webhook", „Cache Invalidation" — du fängst an, diese Wörter zu nutzen, ohne zu wissen, was sie im spezifischen Kontext deines Stacks bedeuten.
- Du verlierst die Fähigkeit zu prototypisieren. Eine zweistündige Coding-Session kann eine Produktfrage beantworten, die drei Stakeholder-Meetings nicht konnten.
- Du wirst abhängig von der Verfügbarkeit von Entwicklern für kleine Entscheidungen. Etwas, das dich früher 20 Minuten gekostet hat, erfordert jetzt Terminfindung.
- Entwickler bemerken das. Nicht alle werden es aussprechen, aber es gibt eine subtile Verschiebung darin, wie sie sich mit einem Gründer auseinandersetzen, der offensichtlich seit Jahren keine Arbeit mehr geleistet hat.
Ich habe beobachtet, wie das bei Menschen passiert ist, die ich respektiere. Gute Menschen, die echte technische Agenturen aufgebaut haben, dann sich allmählich aus ihrer eigenen Expertise heraus abstrahiert haben. Im fünften Jahr führten sie das Unternehmen vollständig und waren darin gut — aber sie hatten etwas verloren, das sie nicht ganz benennen konnten.
---
Das Gegenargument (Und warum ich nicht d'accord gehe)
Der stärkste Fall gegen Gründer-Coding ist die Opportunitätskosten. Paul Graham hat dies in verschiedenen Formen geschrieben — die Idee, dass Gründer Dinge tun sollten, die nicht skalieren, aber auch dass Fokus der einzige echte Vorteil einer frühen Operation ist.Paul Graham has written about this in various forms — the idea that founders should do things that don't scale, but also that focus is the only real advantage an early-stage operation has.
Fair. Wirklich fair.
Aber ich denke, dieses Argument trifft auf Produktgründer bei VC-gestützten Startups sauberer zu als auf Agentur-Gründer und Freelancer. Unser Kontext ist anders. Wir haben kein Laufzeit-Problem, das Coding ablenkt. Wir haben ein Qualitäts- und Vertrauensproblem — und Coding ist Teil davon, wie wir es lösen.
Wenn Seahawk einem Enterprise-Client eine komplexe WordPress-Migration anbietet, ist die Tatsache, dass ein Co-Gründer Datenbanktenstruktur und wp-config-Konstanten im Detail diskutieren kann, keine Kleinigkeit. Das verändert den Raum.
---
Wie ich mir Coding-Zeit schütze, ohne dass es zum Problem wird
Das herauszufinden hat mich Jahre gekostet. Ehrlich gesagt. Ich programmierte früher reaktiv — nur wenn etwas kaputtging oder ein Entwickler feststeckte. Das ist das Schlechteste aus beiden Welten. Du sitzt im Code, aber unter Stress, nie im Flow.
Jetzt mache ich das:
- Blockiere montags und donnerstags morgens 90 Minuten. Keine Anrufe vor 9:30 Uhr an diesen Tagen. Nicht verhandelbar, seit 2022 im Kalender. No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- Führe immer ein "Founder's Project" durch. Etwas Kleines — ein persönliches Tool, ein Client-Micro-Feature, eine interne Automation. Im Moment ist es ein Python-Skript, das unseren Project-Status aus Linear zieht und einen wöchentlichen Digest formatiert. 180 Zeilen, nichts Ausgefallenes. Something small — a personal tool, a client micro-feature, an internal automation. Right now it's a Python script that pulls our project status from Linear and formats a weekly digest. 180 lines, nothing fancy.
- Überprüfe mindestens einen PR pro Woche. Auch wenn es nur zum Lesen ist. Bleib in der Diff. Even if it's just to read. Stay in the diff.
- Baue einmal pro Quartal etwas von Grund auf neu. Eine Landing Page, ein Plugin, eine kleine Integration. Egal was. Der Punkt ist, bei den Fundamentals scharf zu bleiben. A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
Die Gesamtzeit sind vielleicht 4–5 Stunden pro Woche. Das war's. Niemand schlägt vor, dass du Sprints laufen lässt.
---
FAQ
Macht Programmieren dich zu einem schlechteren CEO oder Co-Founder?
Nur wenn du es zulässt, dass es deine eigentlichen Führungsaufgaben verdrängt. Das Problem ist nicht das Programmieren — es ist, Programmieren als Vermeidungsstrategie für die schwierigere Gründer-Arbeit zu nutzen: schwierige Gespräche, Einstellungsentscheidungen, kommerzielles Denken. Wenn du den Editor öffnest, während du mit einem abspringenden Kunden sprechen solltest, ist das ein Problem. Aber 4 Stunden pro Woche am Donnerstagmorgen sind keine Führungsnachlässigkeit.avoidance strategy for the harder founder work: difficult conversations, hiring decisions, commercial thinking. If you're opening the editor when you should be talking to a churning client, that's a problem. But 4 hours a week on a Thursday morning isn't leadership negligence.
Was ist, wenn mein Team mich programmieren sieht und denkt, ich traue ihnen nicht?
Sei direkt dazu. Ich habe meinem Team explizit gesagt: „Wenn ich Code schreibe, ist das kein Signal dafür, dass ich denke, ihr liegt falsch oder seid langsam. So bleibe ich geerdet in dem, was wir tatsächlich bauen." Dieses Gespräch dauert 90 Sekunden und muss meist nur einmal stattfinden.
Ist das realistisch für Gründer mit größeren Teams?
Ehrlich gesagt schwieriger bei 50 Leuten als bei 15. Aber das Prinzip skaliert — auch wenn die Praxis sich ändert. Bei einer bestimmten Größe könnte „Programmieren" bedeuten, Architektur-Entscheidungen zu überprüfen, einen explorativen Spike pro Quartal zu machen oder tiefgreifend zu verstehen, was in einem Lighthouse-Performance-Report steckt, statt den Fix selbst zu schreiben. Der Punkt ist: lass deine technische Fließfertigkeit nicht völlig verkümmern.Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
Wann sollte ein Gründer sich wirklich vom Code zurückziehen?
Wenn Programmieren jemand anderen daran hindert zu wachsen. Wenn ein Entwickler auf deine PR-Review wartet, um seine Arbeit zu mergen, und du bist konsistent der Engpass, ist das das Signal. Tritt von dem kritischen Pfad zurück. Du kannst immer noch Code schreiben — nur nicht im Hauptbranch um 2 Uhr morgens.critical path. You can still write code — just not on the main branch at 2am.
---
Das Programmieren hat mich ehrlich gehalten. Das ist die einfachste Art, wie ich es ausdrücken kann. Wenn du noch immer ein Diff lesen, ein Feature schätzen und etwas Kleines alleine ausliefern kannst – siehst du dein eigenes Business klarer. Du weißt, was wirklich schwierig ist und was nur schlecht erklärt wurde. Diese Klarheit ist mehr wert als die vier Stunden pro Woche, die sie kostet.
Immer noch den Editor öffnen. Wahrscheinlich so lange, bis ich es körperlich nicht mehr kann.