Tout le monde m'a dit d'arrêter.
Pas cruellement — sincèrement, judicieusement, avec une inquiétude du genre que les gens réservent à celui qu'ils pensent gaspiller son temps. « Tu es fondateur maintenant, Gautam. Délègue le code. » Mon cofondateur chez Seahawk Media m'a dit quelque chose de similaire autour de 2018 quand nous avons franchi la barre des cent projets clients actifs simultanément. La logique était solide : les fondateurs devraient 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 confié un brief qui me fait encore 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 package. Délai serré. J'ai confié le projet à un développeur de l'équipe, confiant que c'était exactement le genre de choses 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 je ne l'ai fermé qu'à midi. Je m'en suis sorti. Pas parce que je suis un héros — parce que j'avais réellement mémorisé les patterns du code, l'architecture des hooks WooCommerce, la façon dont woocommerce_before_add_to_cart_button se comporte quand vous avez un type de post personnalisé qui alimente les variations de produits. Je n'avais pas oublié. J'avais juste fait 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
Cela ne signifie pas que je construis chaque fonctionnalité. Ce n'est pas le cas. Seahawk a des développeurs bien meilleurs que moi dans des domaines spécifiques — animation, gestion complexe de l'état React, optimisation des bases de données à grande échelle. Ce n'est pas de la fausse modestie. C'est la vérité.
Mais coder en tant que fondateur signifie que je ne perds jamais le contact avec le travail. Il y a une différence entre gérer un projet et en comprendre un. Quand un développeur me dit « cela prendra deux semaines », je peux poser la bonne question — « est-ce deux semaines parce que l'authentification API est vraiment complexe, ou parce que nous reconstruisons 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 vais poser un commentaire sur une PR. Pas pour microgérer — je le précise explicitement. Mais une note du style « ce filtre s'exécute sur chaque chargement de page, on peut mettre le résultat en cache ? » signale quelque chose d'important : je fais attention au niveau qui compte.
Les développeurs respectent ça. Certains en sont surpris. Et honnêtement, ceux que ça agace — ça m'en dit quelque chose d'utile aussi.annoyed by it — that tells me something useful too.
---
Les outils que j'utilise vraiment en 2024
Ma stack est honteusement sans saveur pour un fondateur tech. VS Code avec une poignée d'extensions (Prettier, GitLens, PHP Intelephense). Un environnement de développement local avec LocalWP — j'ai migré depuis MAMP en 2020 et je ne me suis jamais retourné. Terminal pour tout ce qui concerne Git parce que je n'ai jamais vraiment fait confiance à aucune interface graphique.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 choisis toujours WordPress. On a construit sur Webflow, Shopify, du Laravel personnalisé — mais WordPress est où je suis le plus rapide, et la vitesse compte quand tu fais des interventions courtes plutôt que des sessions de 8 heures 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 dérive. « API », « webhook », « cache invalidation » — tu commences à utiliser ces mots sans 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 regardé cela se produire chez des gens que je respecte. Des gens biens qui ont construit des agences véritablement techniques, puis qui se sont progressivement abstraits de leur propre expertise. À la cinquième année, ils dirigeaient l'entreprise entièrement et ils étaient bons — mais ils avaient perdu quelque chose qu'ils ne pouvaient pas tout à fait nommer.
---
L'argument contraire (et pourquoi je ne suis pas d'accord avec lui)
Le meilleur argument contre le codage des fondateurs est le coût d'opportunité. Paul Graham a écrit à ce sujet sous diverses formes — l'idée que les fondateurs devraient faire des choses qui ne passent pas à l'échelle, mais aussi que la concentration est le seul vrai avantage d'une opération en phase de démarrage.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 fondateurs de produits des startups financées par du capital-risque qu'aux fondateurs d'agences et aux pigistes. Notre contexte est différent. Nous n'avons pas de problème de financement qui détournerait du codage. Nous avons un problème de qualité et de confiance — et le codage en fait partie de la solution.
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
Il m'a fallu des années pour y arriver. Sincèrement. Je codais de manière réactive avant — seulement quand quelque chose cassait ou qu'un développeur était bloqué. C'est le pire des deux mondes. Tu 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.
- J'ai toujours un « projet du fondateur » en cours. 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 fancy. 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 vous laissez ça évincer vos vraies responsabilités de leader. Le problème n'est pas de coder — c'est d'utiliser le code comme stratégie d'évitement pour le travail plus difficile du fondateur : les conversations délicates, les décisions d'embauche, la réflexion commerciale. Si vous ouvrez l'éditeur quand vous devriez parler à un client qui s'en va, là c'est un problème. Mais 4 heures par semaine le jeudi matin, ce n'est pas de la négligence de leader.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'adapte — même si la pratique change. À une certaine taille, « coder » pourrait vouloir dire examiner les décisions architecturales, faire un pic exploratoire par trimestre, ou bien comprendre profondément ce qu'il y a dans un rapport de performance Lighthouse plutôt que d'écrire vous-même la correction. Le point, c'est : ne laissez pas votre fluence 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 code bloque la croissance de quelqu'un d'autre. Si un développeur attend votre revue de PR pour fusionner son travail, et que vous êtes régulièrement le goulot, c'est le signal. Écartez-vous du chemin critique. Vous pouvez toujours écrire du code — juste pas sur la branche principale à 2 du matin.critical path. You can still write code — just not on the main branch at 2am.
---
Le code m'a tenu 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 par toi-même — tu vois ton propre business 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 coûte.
Toujours en train d'ouvrir l'éditeur. Probablement jusqu'à ce que je ne puisse physiquement plus le faire.