Jeder sagte mir, ich solle aufhören.
Nicht grausam, sondern aufrichtig, bewusst, mit der Art von Besorgnis, die Menschen für jemanden reservieren, der ihrer Meinung nach 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 gleichzeitig hundert aktive Kundenprojekte überschritten. Die Logik war schlüssig: Gründer sollten sich mit Systemen, Personalwesen, Pipeline auseinandersetzen. Nicht mit 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)
2019 gab mir ein Kunde ein Briefing, das mich immer noch zum Lachen bringt. Eine mittelständische E-Commerce-Marke, deren Namen ich nicht nennen werde, wollte einen kompletten WooCommerce-Rebuild, einen benutzerdefinierten Produktkonfigurator, alles. Straffer Zeitplan. Ich habe es einem Entwickler aus dem Team zugewiesen, überzeugt, dass dies genau die Art von Aufgabe war, von der ich mich zurückziehen sollte.
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 es erst um 12 Uhr mittags. Ich schaffte es. Nicht, weil ich ein Held bin, sondern weil ich mich tatsächlich an die Code-Muster erinnerte, die WooCommerce Hook-Architektur, die Art, wie woocommerce_before_add_to_cart_button sich verhält, wenn man einen benutzerdefinierten Post Type 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
Das bedeutet nicht, dass ich jede Funktion baue. Das tue ich nicht. Seahawk hat Entwickler, die bei spezifischen Dingen viel besser sind als ich – Animation, komplexes React State Management, Datenbankoptimierung im großen Maßstab. Das ist keine falsche Bescheidenheit. Es ist wahr.
Aber als Gründer zu programmieren bedeutet, dass ich das Gefühl für die Arbeit nie verliere. Es gibt einen Unterschied zwischen der Verwaltung eines Projekts und dem Verstehen eines Projekts. Wenn mir ein Entwickler 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 umbauen, das es bereits in einem WordPress-Plugin gibt?"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
Gelegentlich hinterlasse ich einen PR-Kommentar. Nicht um zu micromanagen – das mache ich explizit klar. Aber ein Kommentar wie „dieser Filter läuft bei jedem Seitenaufruf, können wir das Ergebnis cachen?" signalisiert etwas Wichtiges: Ich zahle auf der Ebene Aufmerksamkeit, die zählt.
Entwickler respektieren das. Manche sind überrascht davon. Und ehrlich gesagt, die, 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 peinlich unsexy für einen Tech-Gründer. VS Code mit einer Handvoll Erweiterungen (Prettier, GitLens, PHP Intelephense). Eine lokale Entwicklungsumgebung mit LocalWP – 2020 bin ich von MAMP umgestiegen und habe nie zurückgeblickt. Terminal für alles, das mit Git zu tun hat, weil ich keiner GUI je vollständig getraut 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 der Arbeit an Kundenprojekten greife ich immer noch zu WordPress. Wir haben auf Webflow, Shopify, custom Laravel gebaut, aber WordPress ist das, womit ich am schnellsten bin, und Geschwindigkeit zählt, wenn man immer wieder kurz reinspringt statt konzentrierte 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 benutzen, 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 das bei Leuten beobachtet, die ich respektiere. Gute Menschen, die echte technische Agenturen aufgebaut haben, sich dann aber schrittweise aus ihrer eigenen Expertise hinausgekürzt haben. Im fünften Jahr führten sie das Business komplett und waren gut darin, aber ihnen fehlte etwas, das sie nicht recht benennen konnten.
---
Das Gegenargument (Und warum ich nicht d'accord gehe)
Das stärkste Argument gegen Founder-Coding ist die Opportunitätskosten. Paul Graham hat darüber in verschiedenen Formen geschrieben – die Idee, dass Founder Dinge tun sollten, die nicht skalieren, aber auch, dass Fokus der einzige echte Vorteil einer Early-Stage-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 gilt sauberer für Product Founder bei VC-gestützten Startups als für Agency Founder und Freelancer. Unser Kontext ist anders. Wir haben kein Runway-Problem, von dem Coding ablenkt. Wir haben ein Qualitäts- und Vertrauensproblem, und Coding ist Teil, 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 mir Jahre gekostet. Wirklich. Ich habe früher nur reaktiv programmiert, nur wenn etwas kaputt war oder ein Developer stecken blieb. Das ist das Schlechteste aus beiden Welten. Du bist im Code, aber gestresst, 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 jederzeit ein "Founder-Projekt" parallel. Etwas Kleines, ein persönliches Tool, eine Client-Micro-Feature, eine interne Automation. Gerade jetzt ist es ein Python-Skript, das unseren Projektstatus aus Linear zieht und einen wöchentlichen Digest formatiert. 180 Zeilen, nichts Besonderes. 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 echte Leadership-Verantwortung verdrängt. Das Problem ist nicht Coding, es ist Coding als Vermeidungsstrategie für die schwierigere Founder-Arbeit zu nutzen: schwierige Gespräche, Einstellungsentscheidungen, kommerzielles Denken. Wenn du den Editor öffnest, wenn du mit einem abspringenden Kunden sprechen solltest, das ist ein Problem. Aber 4 Stunden pro Woche am Donnerstagmorgen ist keine Leadership-Fahrlä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 mit 50 Leuten als mit 15. Aber das Prinzip skaliert, selbst wenn die Praxis sich ändert. Bei einer bestimmten Größe könnte "Coding" bedeuten, Architektur-Entscheidungen zu reviewen, einen explorativen Spike pro Quartal zu machen, oder wirklich zu verstehen, was in einem Lighthouse-Performance-Report drin ist, anstatt den Fix selbst zu schreiben. Der Punkt ist: Lass deine technische Flüssigkeit nicht vollständig 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 Coding jemand anderen am Wachsen hindert. Wenn ein Developer auf dein PR-Review wartet, um seine Arbeit zu mergen, und du bist konsistent der Bottleneck, das ist das Signal. Tritt vom kritischen Pfad zurück. Du kannst immer noch Code schreiben, nur nicht im Main-Branch um 2 Uhr morgens.critical path. You can still write code, just not on the main branch at 2am.
---
Programmieren hielt mich ehrlich. Das ist die einfachste Art, wie ich es ausdrücken kann. Wenn du noch immer einen Diff lesen, ein Feature schätzen und eine kleine Sache selbst ausliefern kannst, siehst du dein eigenes Geschäft klarer. Du weißt, was wirklich schwierig ist und was nur schlecht erklärt ist. 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.