Tout le monde m'a dit d'arrêter.
Pas cruellement, sincèrement, délibérément, avec cette sorte de préoccupation que les gens réservent à quelqu'un qu'ils pensent voir gaspiller son temps. « Tu es fondateur maintenant, Gautam. Délègue le code. » Mon cofondateur chez Seahawk Media a dit quelque chose de similaire vers 2018, quand nous avons dépassé une centaine de projets clients actifs simultanément. La logique était solide : les fondateurs doivent penser aux systèmes, à l'embauche, au pipeline. Pas aux 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.
J'ai ignoré ce conseil. Et je suis content d'avoir le fait.
---
Le Moment Où J'Ai Failli Arrêter de Coder (Et Ne L'Ai Pas Fait)
En 2019, un client m'a remis un brief qui me fait toujours rire. Une marque e-commerce de taille moyenne, je ne la nommerai pas, voulait une refonte complète de WooCommerce, un configurateur de produits personnalisé, tout le paquet. Délai serré. Je l'ai confiée à un développeur de l'équipe, confiant que c'était exactement le genre de chose dont je devais me retirer.
Trois semaines plus tard, le développeur a démissionné. Des raisons personnelles, tout à fait compréhensibles. Mais nous avions un configurateur à moitié construit, un client qui me pressait, et une base de code que seule une personne avait entièrement comprise.
J'ai ouvert VS Code ce dimanche à 7h du matin et ne l'ai fermé qu'à midi. Je m'en suis sorti. Pas parce que je suis un héros, mais parce que je me souvenais encore des patterns de code, de l'architecture des hooks WooCommerce, de la façon dont woocommerce_before_add_to_cart_button se comporte quand vous avez un custom post type qui alimente les variations de produits. Je n'avais pas oublié. Je faisais juste semblant d'avoir avancé.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.
Ce projet a complètement remodélé ma façon de concevoir mon rôle.
---
Ce que "Founder Who Codes" signifie vraiment
Ça ne signifie pas que je crée chaque fonctionnalité. Je ne le fais pas. Seahawk a des développeurs bien meilleurs que moi dans des domaines spécifiques : l'animation, la gestion d'état React complexe, l'optimisation des bases de données à grande échelle. Ce n'est pas de la fausse modestie. C'est vrai.
Mais coder en tant que fondateur signifie que je ne perds jamais la sensation du travail. Il y a une différence entre gérer un projet et le comprendre. Quand un développeur me dit « ça prendra deux semaines », je peux poser la bonne question : « c'est deux semaines parce que l'authentification API est véritablement complexe, ou parce qu'on reconstruit quelque chose qui existe déjà dans un plugin WordPress ? »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?"
On ne peut pas poser cette question de loin. On ne peut tout simplement pas.
Le problème d'estimation
Voilà le truc avec les estimations logicielles : ce sont des histoires que les développeurs se racontent autant qu'ils les racontent aux clients. J'ai vu un dev senior estimer quatre jours pour un endpoint REST API WordPress custom qui m'a pris six heures une fois que je me suis assis avec lui et qu'on a bien défini le scope. Pas parce qu'il était paresseux. Parce que ni l'un ni l'autre n'avions vraiment compris ce que l'endpoint devait faire.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.
Quand tu codes régulièrement, ton détecteur de conneries sur les estimations s'améliore. Dramatiquement.
---
Ça fait de moi un meilleur client, en interne
Un truc que personne ne te dit sur la gestion d'une agence : tes développeurs sont tes clients internes. Tu dois les vendre sur les bonnes décisions exactement comme tu vends tes clients externes. Et tu perds cette capacité le moment où tu arrêtes de parler leur langage.
J'utilise Figma pour les handoffs de design. J'utilise Git (spécifiquement GitHub, on a tout déplacé là depuis Bitbucket en 2021). J'écris des vrais tickets dans Linear avec assez de détails pour qu'un développeur puisse commencer sans appel de lancement. Rien que ce dernier truc nous a probablement sauvé 40 minutes par projet, et on en lance beaucoup, des projets.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.
Rien de tout ça n'est possible si tu es devenu complètement "big picture." Tu dois savoir ce qu'un développeur a besoin dans un ticket. Tu le sais seulement si tu as été de l'autre côté.
La relecture de code que le patron ne s'attend pas à recevoir
Occasionnellement, je commenterai une PR. Pas pour micromanager, je le précise explicitement. Mais une note du type « ce filtre s'exécute à chaque chargement de page, on peut cacher le résultat ? » signale quelque chose d'important : je suis attentif au niveau qui compte.
Les développeurs respectent ça. Certains en sont surpris. Et honnêtement, ceux qui en sont irrités, ça me dit aussi quelque chose d'utile.annoyed by it, that tells me something useful too.
---
Les outils que j'utilise vraiment en 2024
Mon stack est ridiculement insexy pour un fondateur tech. VS Code avec une poignée d'extensions (Prettier, GitLens, PHP Intelephense). Un environnement de développement local tournant sur LocalWP, j'ai abandonné MAMP en 2020 et je ne me suis jamais regardé en arrière. Terminal pour tout ce qui est lié à Git, parce que je n'ai jamais fait entièrement confiance à un GUI.LocalWP, I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
Quand je travaille sur des projets clients, je reviens toujours à WordPress. On a construit sur Webflow, Shopify, du Laravel custom, mais WordPress c'est où je suis le plus rapide, et la rapidité compte quand tu fais des allers-retours plutôt que des sessions de 8 heures bien concentrées.
J'ai utilisé Coolors.co mardi dernier pour extraire une palette de marque pour un correctif rapide sur la page d'accueil d'un client. Ça m'a pris quatre minutes au total. Ça m'aurait pris une heure pour briefer un designer, attendre et relire. C'est l'avantage du fondateur qui code en miniature.
---
Ce que tu perds vraiment quand tu arrêtes
La plupart des fondateurs qui s'éloignent de l'éditeur se convainquent qu'ils resteront techniques par osmose. Ils l'absorberont à partir des standups et des fils Slack. Ils ne le feront pas.
Voici ce qui se passe vraiment :
- Ton vocabulaire s'érode. « API », « webhook », « cache invalidation », tu commences à utiliser ces mots sans vraiment savoir ce qu'ils signifient dans le contexte spécifique de ta stack.
- Vous perdez la capacité à prototyper. Une session de codage de deux heures peut répondre à une question produit que trois réunions de parties prenantes ne pourraient pas résoudre.
- Vous devenez dépendant de la disponibilité des développeurs pour les petites décisions. Quelque chose qui vous prenait 20 minutes auparavant nécessite maintenant de programmer une réunion.
- Les développeurs le remarquent. Pas tous le diront, mais il y a un changement subtil dans la façon dont ils s'engagent avec un fondateur qui clairement n'a pas touché au travail depuis des années.
J'ai vu ça arriver à des gens que je respecte. Des gens bien qui ont construit des agences vraiment techniques, puis ils se sont progressivement abstraits de leur propre expertise. À l'année cinq, ils géraient l'entreprise complètement et ils étaient bons, mais ils avaient perdu quelque chose qu'ils ne savaient pas nommer.
---
L'argument contraire (et pourquoi je ne suis pas d'accord avec lui)
Le meilleur argument contre le founder-coding c'est le coût d'opportunité. Paul Graham a écrit là-dessus sous différentes formes, l'idée que les founders doivent faire des choses qui ne passent pas à l'échelle, mais aussi que la concentration est le seul vrai avantage d'une opération au stade initial.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.
C'est juste. Véritablement juste.
Mais je pense que cet argument s'applique plus clairement aux product founders des startups financées par du VC qu'aux founders d'agences et aux freelances. Notre contexte est différent. On n'a pas un problème de runway que le coding détournerait. On a un problème de qualité et de confiance, et le coding est une partie de comment on le résout.
Quand Seahawk propose à un client d'entreprise une migration WordPress complexe, le fait qu'un cofondateur puisse discuter en détail de la structure des tables de base de données et des constantes wp-config n'est pas un détail. Ça change la dynamique de la réunion.
---
Comment je protège mon temps de code sans que ça devienne un problème
Ça m'a pris des années de comprendre ça. Franchement. Je codais réactivement avant, seulement quand quelque chose cassait ou qu'un développeur était bloqué. C'est le pire des deux mondes. T'es dans le code mais stressé, jamais en flow.
Maintenant je fais ça :
- Je bloque 90 minutes le lundi et jeudi matin. Pas d'appels avant 9h30 ces jours-là. Non-négociable, c'est dans le calendrier depuis 2022. No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- Garde un « projet du founder » en cours en permanence. Quelque chose de petit, un outil personnel, une micro-feature client, une automation interne. En ce moment c'est un script Python qui récupère notre statut de projet depuis Linear et formate un digest hebdomadaire. 180 lignes, rien de fantaisiste. 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.
- Je revois au moins une PR par semaine. Même si c'est juste pour lire. Je reste dans le diff. Even if it's just to read. Stay in the diff.
- Je reconstris quelque chose from scratch une fois par trimestre. Une landing page, un plugin, une petite intégration. N'importe quoi. L'idée c'est de rester aiguisé sur les fondamentaux. A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
Le temps total c'est peut-être 4-5 heures par semaine. C'est tout. Personne te suggère de faire des sprints.
---
FAQ
Est-ce que coder vous rend moins bon PDG ou co-fondateur ?
Uniquement si tu le laisses étouffer tes responsabilités de leadership réelles. Le problème c'est pas le coding, c'est d'utiliser le coding comme stratégie d'évitement pour le travail de founder plus difficile : les conversations difficiles, les décisions d'embauche, la réflexion commerciale. Si tu ouvres l'éditeur quand tu devrais parler à un client qui s'en va, c'est un problème. Mais 4 heures par semaine le jeudi matin c'est pas de la négligence du leadership.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.
Et si mon équipe me voit coder et pense que je ne leur fais pas confiance ?
Soyez direct. J'ai dit explicitement à mon équipe : « Quand j'écris du code, ce n'est pas un signal que je pense que vous vous trompez ou que vous êtes lent. C'est comment je reste enraciné dans ce qu'on construit vraiment. » Cette conversation prend 90 secondes et la plupart du temps ne doit avoir lieu qu'une fois.
Est-ce réaliste pour les fondateurs qui gèrent des équipes plus grandes ?
Honnêtement, c'est plus difficile à 50 personnes qu'à 15. Mais le principe s'étend, même si la pratique change. À une certaine taille, « coder » peut vouloir dire examiner des décisions architecturales, faire un spike exploratoire par trimestre, ou comprendre profondément ce qui se cache dans un rapport Lighthouse plutôt que d'écrire la correction toi-même. Le point c'est : ne laisse pas ta fluidité technique s'atrophier complètement.Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
Quand un fondateur devrait-il vraiment s'écarter du code ?
Quand le coding bloque quelqu'un d'autre de grandir. Si un développeur attend ta review de PR pour merger son travail, et tu es systématiquement le goulot, c'est le signal. Recule du chemin critique. Tu peux toujours écrire du code, juste pas sur la branche principale à 2h du matin.critical path. You can still write code, just not on the main branch at 2am.
---
Le code m'a gardé honnête. C'est la façon la plus simple que je connaisse de l'exprimer. Quand tu peux encore lire un diff, estimer une fonctionnalité et déployer une petite chose de ton côté, tu vois ton propre métier plus clairement. Tu sais ce qui est vraiment difficile et ce qui est juste mal expliqué. Cette clarté vaut plus que les quatre heures par semaine qu'elle te coûte.
Toujours en train d'ouvrir l'éditeur. Probablement jusqu'à ce que je ne puisse physiquement plus le faire.