Todos me dijeron que parara.
No fue cruel — fue genuino, aconsejado, con el tipo de preocupación que la gente reserva para alguien que cree está perdiendo su tiempo. "Eres un fundador ahora, Gautam. Delega el código." Mi cofundador en Seahawk Media dijo algo parecido alrededor de 2018 cuando cruzamos cien proyectos de clientes activos simultáneamente. La lógica era sólida: los fundadores deberían pensar en sistemas, contratación, pipeline. No en 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.
Ignoré ese consejo. Y me alegra haberlo hecho.
---
El Momento en que Casi Dejo de Codificar (Y No Lo Hice)
Allá por 2019, un cliente me entregó un brief que todavía me hace reír. Una marca de e-commerce de tamaño medio —no voy a nombrarla— quería un rebuild completo de WooCommerce, un configurador de productos personalizado, todo. Plazo ajustado. Se lo asigné a un desarrollador del equipo, confiado en que era exactamente el tipo de cosa de la que debería estar apartándome.
Tres semanas después, el desarrollador se fue. Razones personales, completamente comprensibles. Pero teníamos un configurador a medio construir, un cliente presionándome, y una base de código que solo una persona había entendido completamente.
Abrí VS Code ese domingo a las 7am y no lo cerré hasta el mediodía. Lo logré. No porque sea un héroe — porque en realidad recordaba los patrones de código, la arquitectura de hooks de WooCommerce, la forma en que woocommerce_before_add_to_cart_button se comporta cuando tienes un post type personalizado alimentando variaciones de producto. No lo había olvidado. Solo había estado fingiendo que había avanzado.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.
Ese proyecto reformuló completamente cómo pienso mi rol.
---
Lo Que "Founder Who Codes" Realmente Significa
No significa que esté construyendo cada feature. No lo estoy. Seahawk tiene desarrolladores mucho mejores que yo en cosas específicas — animación, manejo complejo de estado en React, optimización de bases de datos a escala. No es falsa modestia. Es verdad.
Pero programar como fundador significa que nunca pierdo la sensación del trabajo. Hay una diferencia entre gestionar un proyecto y entender uno. Cuando un desarrollador me dice "esto tomará dos semanas," puedo hacer la pregunta correcta — "¿son dos semanas porque la autenticación de API es genuinamente compleja, o porque estamos reconstruyendo algo que ya existe en un plugin de 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?"
No puedes hacer esa pregunta desde 10,000 pies de altura. Simplemente no puedes.
El Problema de la Estimación
Esto es lo que pasa con las estimaciones de software: son historias que los desarrolladores se cuentan a sí mismos tanto como se las cuentan a los clientes. He visto a un desarrollador senior cotizar cuatro días para un endpoint REST de WordPress personalizado que terminó tomando seis horas una vez que me senté con él y lo alcancé adecuadamente. No porque fuera perezoso. Porque ninguno de nosotros había profundizado en lo que el endpoint realmente necesitaba hacer.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.
Cuando codificas regularmente, tu detector de mentiras para las estimaciones mejora. Dramáticamente.
---
Me Hace un Mejor Cliente, Internamente
Una cosa que nadie te dice sobre dirigir una agencia: tus desarrolladores son tus clientes internos. Tienes que convencerlos de buenas decisiones tal como convences a clientes externos. Y pierdes esa capacidad en el momento en que dejas de hablar su idioma.
Uso Figma para entregas de diseño. Uso Git (específicamente GitHub, migramos todo allá desde Bitbucket en 2021). Escribo tickets reales en Linear con suficiente especificidad para que un desarrollador pueda empezar a trabajar sin una llamada de inicio. Solo ese último aspecto probablemente nos ha ahorrado unos 40 minutos por proyecto, y ejecutamos muchos proyectos.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.
Nada de eso es posible si has desaparecido completamente en la "visión general". Necesitas saber qué necesita un desarrollador en un ticket. Solo lo sabes si has estado del otro lado.
La Revisión de Código que Nadie Espera del Jefe
Ocasionalmente dejaré un comentario en una PR. No para microgestionar — lo hago explícito. Pero una nota como "este filtro se está ejecutando en cada carga de página, ¿podemos cachear el resultado?" señala algo importante: estoy prestando atención al nivel que importa.
Los desarrolladores respetan eso. Algunos se sorprenden por ello. Y honestamente, los que se molestan por ello — eso también me dice algo útil.annoyed by it — that tells me something useful too.
---
Las herramientas que realmente uso en 2024
Mi stack es vergonzosamente poco atractivo para un fundador de tech. VS Code con un puñado de extensiones (Prettier, GitLens, PHP Intelephense). Un entorno de desarrollo local corriendo LocalWP — cambié desde MAMP en 2020 y nunca miré atrás. Terminal para todo lo relacionado con Git porque nunca confié completamente en ninguna GUI.LocalWP — I switched from MAMP in 2020 and never looked back. Terminal for everything Git-related because I never fully trusted any GUI.
Cuando trabajo en proyectos de clientes sigo eligiendo WordPress. Hemos construido en Webflow, Shopify, custom Laravel — pero WordPress es donde soy más rápido, y la velocidad importa cuando estás entrando y saliendo en lugar de hacer sesiones enfocadas de 8 horas.
Usé Coolors.co el martes pasado para sacar una paleta de marca para un arreglo rápido en la landing page de un cliente. Me tomó cuatro minutos en total. Me habría tomado una hora hacer el briefing de un diseñador, esperar, y revisar. Esa es la ventaja de un fundador que codifica en miniatura.
---
Qué realmente pierdes cuando paras
La mayoría de los fundadores que se apartan del editor se convencen a sí mismos de que se mantendrán técnicos por ósmosis. Lo absorberán de los stand-ups y threads de Slack. No lo harán.
Esto es lo que realmente sucede:
- Tu vocabulario se desvía. "API," "webhook," "cache invalidation" — empiezas a usar estas palabras sin saber qué significan en el contexto específico de tu stack.
- Pierdes la capacidad de prototipear. Una sesión de dos horas de código puede responder una pregunta de producto que tres reuniones de stakeholders no pudieron.
- Te vuelves dependiente de la disponibilidad de desarrolladores para decisiones pequeñas. Algo que solía tomarte 20 minutos ahora requiere agendar una reunión.
- Los desarrolladores lo notan. No todos lo dirán, pero hay un cambio sutil en cómo se relacionan con un fundador que claramente no ha tocado el trabajo en años.
He visto esto sucederle a gente que respeto. Personas buenas que construyeron agencias genuinamente técnicas, luego gradualmente se abstrajeron de su propia experiencia. Para el año cinco estaban dirigiendo el negocio completamente y eran buenos en eso — pero habían perdido algo que no podían nombrar.
---
El Contraargumento (Y Por Qué Estoy en Desacuerdo)
El caso más fuerte en contra de que los fundadores programen es el costo de oportunidad. Paul Graham ha escrito sobre esto en varias formas — la idea de que los fundadores deben hacer cosas que no escalan, pero también que el enfoque es la única ventaja real que tiene una operación en etapa temprana.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.
Justo. Genuinamente justo.
Pero creo que ese argumento se aplica más claramente a fundadores de productos en startups respaldadas por VC que a fundadores de agencias y freelancers. Nuestro contexto es diferente. No tenemos un problema de runway que la programación distraiga. Tenemos un problema de calidad y confianza — y la programación es parte de cómo lo resolvemos.
Cuando Seahawk presenta una migración compleja de WordPress a un cliente empresarial, el hecho de que un co-fundador pueda discutir la estructura de tablas de base de datos y constantes de wp-config en detalle no es algo menor. Cambia el ambiente.
---
Cómo Protejo Tiempo de Programación Sin Que Se Convierta en un Problema
Me tomó años descubrirlo. En serio. Solía programar reactivamente — solo cuando algo se rompía o un desarrollador estaba atrapado. Es lo peor de ambos mundos. Estás en el código pero estresado, nunca en flujo.
Ahora hago esto:
- Bloqueo 90 minutos los lunes y jueves por la mañana. Sin llamadas antes de las 9:30am esos días. No negociable, en el calendario desde 2022. No calls before 9:30am those days. Non-negotiable, in the calendar since 2022.
- Mantengo un "proyecto del fundador" en ejecución todo el tiempo. Algo pequeño — una herramienta personal, una micro-feature para un cliente, una automatización interna. Ahora mismo es un script en Python que extrae el estado de nuestros proyectos de Linear y genera un resumen semanal. 180 líneas, nada sofisticado. 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.
- Reviso al menos un PR por semana. Aunque sea solo para leer. Mantengo el seguimiento del diff. Even if it's just to read. Stay in the diff.
- Reconstruyo algo desde cero una vez por trimestre. Una landing page, un plugin, una pequeña integración. Lo que sea. El punto es mantenerme agudo en los fundamentos. A landing page, a plugin, a small integration. Whatever. The point is staying sharp on fundamentals.
El tiempo total es quizá 4-5 horas por semana. Eso es todo. Nadie está sugiriendo que hagas sprints.
---
FAQ
¿Programar te convierte en un peor CEO o cofundador?
Solo si dejas que se apodere de tus responsabilidades de liderazgo real. El problema no es programar — es usar la programación como estrategia de evasión del trabajo fundacional más difícil: conversaciones complicadas, decisiones de contratación, pensamiento comercial. Si abres el editor cuando deberías estar hablando con un cliente que se va, eso es un problema. Pero 4 horas a la semana el jueves por la mañana no es negligencia de liderazgo.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.
¿Y si mi equipo me ve programando y piensa que no confío en ellos?
Sé directo al respecto. He sido explícito con mi equipo: "Cuando escribo código, no es una señal de que creo que estás equivocado o eres lento. Es cómo me mantengo conectado con lo que realmente construimos." Esa conversación toma 90 segundos y generalmente solo necesita ocurrir una vez.
¿Es esto realista para fundadores que dirigen equipos más grandes?
Honestamente, más difícil con 50 personas que con 15. Pero el principio escala — aunque la práctica cambie. A cierto tamaño, "programar" podría significar revisar decisiones de arquitectura, hacer un spike exploratorio por trimestre, o entender profundamente qué hay dentro de un reporte de rendimiento de Lighthouse en lugar de escribir la solución tú mismo. El punto es: no dejes que tu fluidez técnica se atrofie completamente.Lighthouse performance report rather than writing the fix yourself. The point is: don't let technical fluency atrophy entirely.
¿Cuándo debe un fundador genuinamente alejarse del código?
Cuando programar está bloqueando el crecimiento de alguien más. Si un desarrollador está esperando tu revisión de PR para mergear su trabajo, y consistentemente eres el cuello de botella, esa es la señal. Aléjate del camino crítico. Aún puedes escribir código — solo no en la rama principal a las 2am.critical path. You can still write code — just not on the main branch at 2am.
---
El código me mantuvo honesto. Es la forma más simple que conozco de decirlo. Cuando todavía puedes leer un diff, estimar una feature y desplegar algo pequeño por tu cuenta — ves tu propio negocio con más claridad. Sabes qué es realmente difícil y qué está simplemente mal explicado. Esa claridad vale más que las cuatro horas a la semana que cuesta.
Sigo abriendo el editor. Probablemente seguiré haciéndolo hasta que físicamente no pueda.