De ingeniero fundador a líder tecnológico: hacer crecer un equipo y un producto en América Latina
_Descargo de responsabilidad: El software descrito en este artículo es propiedad intelectual de Soy Más de las Américas. El propósito de este ensayo es compartir mi crecimiento personal junto con el desarrollo del producto, no revelar detalles técnicos exclusivos.
La oficina vacía
Hay un tipo específico de libertad que conlleva ser el único ingeniero en una startup.
Al principio, los cofundadores dejaban la oficina durante días seguidos, dirigiéndose a los primeros creyentes, persiguiendo los primeros cheques, contando la historia de lo que estábamos construyendo. Y estaría allí solo, con un editor en blanco y total libertad creativa.
Eran los días de la pura imaginación. ¿Cómo podría este producto servir mejor a su grupo demográfico? ¿Cómo podríamos integrar herramientas de inteligencia artificial para hacerlas accesibles a usuarios que nunca habían interactuado con algo como esto? No hubo partes interesadas que alinear, ni ceremonias de sprint, ni revisiones de solicitudes de extracción. Sólo un constructor y un problema.
Siempre recordaré esa etapa con profundo cariño. No porque fuera fácil, sino porque era mío.
El primer comentario
Luego llegaron los probadores beta y todo cambió.
La retroalimentación tiene una manera de humillar sus suposiciones. Características que pensé que eran personas intuitivas y confundidas. Los flujos que consideraba elegantes se sentían torpes. La brecha entre lo que imaginé y lo que experimentaron los usuarios fue la primera lección real: el producto no es lo que construyes, es lo que ellos usan.
Rápidamente quedó claro que mis primeros prototipos de ingeniería necesitaban algo que no podía proporcionar solo: diseño real. No “CSS de desarrollador”: comunicación visual real que podría transmitir la visión de marca de los fundadores. El tipo de trabajo que hace que un usuario confíe en un producto incluso antes de hacer clic en algo.
Construyendo el equipo
El primer empleado fue un diseñador. Esa única adición transformó el producto más que cualquier refactor que haya hecho.
Luego vinieron los ingenieros. Tuve la fortuna de contar con personas en las que confiaba: ingenieros con los que había trabajado antes, personas cuyo criterio respetaba. También colaboramos estrechamente con líderes de otros equipos internos, lo que me enseñó cómo diferentes grupos dentro de la misma empresa pueden tener culturas de trabajo tremendamente diferentes.
Ver crecer a ese equipo fue una de las experiencias más gratificantes de mi carrera. No por lo que enviamos (aunque enviamos mucho), sino porque pude presenciar el empoderamiento de mis colegas: momentos en los que un ingeniero junior que había dudado en los stand-ups comenzó a proponer cambios de arquitectura con confianza, o en los que un pasante presentó su trabajo a toda la empresa por primera vez.
La transición
Mi día a día cambió por completo.
Antes: Escribir código. Imagínese el producto. Barco.
Después: Revisar las solicitudes de extracción. Documente el código base para que los nuevos ingenieros puedan incorporarse. Mantenga largas conversaciones sobre arquitectura, escalabilidad y estrategia técnica a largo plazo.
Esa última parte fue la que más me sorprendió. No sabía que necesitaba aprender a debatir sobre arquitectura. Cuando eres un constructor en solitario, tus decisiones técnicas son monólogos. Cuando lideras un equipo, estos se convierten en diálogos y, a veces, en desacuerdos.Diferentes ingenieros aportaron diferentes perspectivas. A veces desafiaban patrones que había usado durante años. Y aquí está la incómoda verdad: a veces tenían razón.
La paradoja de la herramienta
Una de las lecciones más sutiles: no siempre puedes usar tus herramientas favoritas.
Cuando eres solo tú, tu pila es aquello con lo que seas más rápido. Cuando lideras un equipo, la pila debe coincidir con el conjunto de habilidades del equipo. Es más fácil adaptar sus herramientas a su gente que adaptar su gente a sus herramientas.
Aprendí esto de la manera más difícil: defendiendo una tecnología que amaba, solo para darme cuenta de que el costo de incorporación para el resto del equipo nos retrasaría semanas. La opción “inferior” que todos ya conocían era la opción superior para el envío.
Dejar ir el código
La parte más difícil de la transición no fue aprender a liderar. Estaba aprendiendo a liberar.
Mi mejor ingeniero no escribía código como yo. Mantendríamos conversaciones detalladas sobre patrones específicos: yo tendría un enfoque que estaba convencido de que funcionaría y él tendría uno diferente. A veces íbamos y veníamos, cada uno exponiendo su caso.
Lo que finalmente aprendí: confiar en un ingeniero no significa estar de acuerdo con él. Significa darles tu respuesta honesta, escuchar su respuesta honesta y luego, cuando puedan expresar que entienden tu preocupación pero aún creen en su enfoque, empoderarlos con esa decisión.
Ese fue el momento en que pasé de “liderar quién codifica” a “liderar quién hace crecer a los ingenieros”. Es un trabajo fundamentalmente diferente. Y es más difícil. Y importa más.
Los pasantes
Una breve nota sobre la tutoría de pasantes, porque merece su propio espacio.
Las mejores cosas que les enseñé no tuvieron nada que ver con el código:
- Cómo pensar en los problemas antes de buscar soluciones.
- Cómo presentar su trabajo a un equipo, no sólo el qué, sino el por qué.
- ¿Cómo hacer preguntas que no sean “¿cómo hago X?” pero “¿qué debo considerar al decidir entre X e Y?”
Ver a alguien desarrollar esa metahabilidad (la capacidad de pensar sobre su propio pensamiento) fue más satisfactorio que cualquier despliegue.
La parte más difícil: irse
En algún momento, llegó el momento de seguir adelante.
No quiero romantizarlo. Dejar un equipo que usted creó (personas que contrató, asesoró, debatió y celebró) es realmente doloroso. Hay un tipo específico de dolor al alejarse de algo que todavía tiene sus huellas digitales en todo el código base.
Pero el producto llegó a más de 100.000 usuarios. El equipo era lo suficientemente fuerte como para seguir adelante sin mí. Y las relaciones sobrevivieron a la partida; hasta el día de hoy, esos colegas son amigos cercanos.
Esa podría ser la mejor medida para saber si usted dirigió bien: no si el código estaba limpio, sino si la gente todavía lo llama después de que se va.
Lo que llevo adelante1. La libertad creativa es un privilegio, no un derecho. Disfruta de la fase en solitario. No dura.
- Las herramientas de tu equipo > tus herramientas favoritas. Envía con lo que el equipo sabe.
- Los debates sobre arquitectura no son amenazas, son el trabajo. Si nadie está en desacuerdo contigo, nadie está pensando.
- El empoderamiento es permitir que alguien tome una decisión que tú no tomarías. Y estar de acuerdo con ello.
- La parte más difícil siempre es irse. Construye algo que valga la pena perderse.
Diego Jiménez Vergara — Ingeniero de Infraestructura de IA y DevOps. Ex ingeniero fundador y líder tecnológico de Soy+.