Enseñar a los ingenieros a pensar como fundadores

Cada año en Harbour.Space University en Barcelona, me pongo delante de una sala de estudiantes de desarrollo y data science y les digo algo que no quieren oír: ser un gran programador no es suficiente. No si quieres construir cosas que importen. No si quieres liderar.

Creé el módulo "Developer to CTO" para cerrar la brecha entre lo que los programas de ingeniería enseñan y lo que la industria realmente demanda. El módulo funciona como un intensivo diario. Cubrimos gestión de proyectos, diseño de sistemas, estrategia de negocio y construcción de ventures. Los estudiantes forman equipos y construyen proyectos reales desde cero durante el curso.

Esto es lo que he aprendido enseñándolo.

La primera sorpresa: nadie te enseña a decir no

El primer ejercicio que doy a los estudiantes es simple. Les entrego un brief de producto con quince funcionalidades y les digo que tienen presupuesto para construir tres. Tienen que elegir cuáles y explicar por qué.

Casi todos los equipos lo pasan mal con esto. Han pasado años en entornos donde el objetivo es resolver cada problema, aprobar cada test, implementar cada requisito. La idea de dejar funcionalidades sobre la mesa deliberadamente les parece incorrecta.

Pero es la habilidad más importante que necesita un líder técnico. En Cantoo, alcanzamos la rentabilidad precisamente porque dijimos no a funcionalidades que no generaban ingresos directamente. Podríamos haber construido un dashboard bonito. Podríamos haber añadido analytics. Podríamos haber soportado más protocolos. En vez de eso, construimos un motor de enrutamiento de voz, un sistema de facturación y una API. Eso fue todo. Y fue suficiente.

Los estudiantes se quedan impactados cuando les digo que decir no a una buena idea es más difícil y más valioso que decir sí. Al final del módulo, lo entienden.

Modelos de negocio antes que código

Empiezo el módulo con modelos de negocio, no con diagramas de arquitectura. Esto confunde a los estudiantes al principio. Se apuntaron a un curso técnico. ¿Por qué estamos hablando de unit economics?

Porque cada decisión de arquitectura es, en última instancia, una decisión de negocio. La elección entre monolito y microservicios no es solo técnica. Determina lo rápido que puedes entregar, cuántos ingenieros necesitas y cuánto cuesta tu infraestructura. Si no entiendes el contexto de negocio, vas a optimizar para lo equivocado.

Les llevo por ejemplos reales. En OneRagtime, construimos tres productos separados (Platform, Core, Deepdive) porque el negocio de VC tenía tres grupos de usuarios distintos con necesidades y patrones de uso diferentes. Un solo monolito habría sido más simple de construir pero imposible de iterar de forma independiente. La arquitectura seguía al negocio, no al revés.

En Cantoo, elegimos un enfoque monolítico inicialmente porque éramos dos personas y necesitábamos entregar rápido. El contexto de negocio exigía velocidad por encima de elegancia. Refactorizamos después cuando el negocio creció.

Los estudiantes que entienden esto se convierten en mejores arquitectos. No eligen tecnologías porque son interesantes. Las eligen porque sirven al negocio.

La simulación de equipo

La parte más transformadora del módulo es el proyecto de venture. Los estudiantes forman equipos de cuatro o cinco y tienen que construir algo real. No un prototipo. No un mockup. Un producto funcional con un modelo de negocio, un mercado objetivo y un plan de sostenibilidad.

He visto a programadores individuales brillantes desmoronarse completamente en este ejercicio. Quieren escribir todo el código ellos mismos. Se resisten a delegar. Pasan tres días perfeccionando una funcionalidad que nadie pidió mientras el producto principal sigue sin terminar.

Esto es exactamente lo que les pasa a los managers de ingeniería primerizos en el mundo real. La transición de contribuidor individual a líder es dolorosa porque exige soltar lo que te hizo exitoso en primer lugar.

Les digo a mis estudiantes: tu trabajo ya no es escribir el mejor código. Tu trabajo es asegurarte de que el mejor código se escriba. Es una habilidad fundamentalmente distinta.

Lo que más sorprende a los estudiantes

Tres cosas pillan por sorpresa a los estudiantes sistemáticamente.

Conciencia de costes. La mayoría de los estudiantes nunca han pensado en cuánto cuestan sus decisiones técnicas. Cuando les muestro la factura de AWS de una startup real y explico cómo las decisiones de arquitectura impactan directamente el burn rate, algo hace clic. De repente, ese microservicio extra o esa funcionalidad en tiempo real no es solo una decisión técnica. Es una decisión financiera.

La brecha de comunicación. Los estudiantes descubren que explicar una decisión técnica a un interlocutor no técnico es genuinamente difícil. Les hago presentar sus decisiones de arquitectura como si yo fuera un inversor. Sin jerga permitida. Si no puedes explicar por qué elegiste PostgreSQL en lugar de MongoDB en términos que un perfil de negocio entienda, probablemente no lo has pensado con suficiente claridad.

Entregar supera a la perfección. Pongo plazos ajustados deliberadamente. Los equipos que dedican demasiado tiempo a la arquitectura nunca terminan. Los equipos que entregan algo imperfecto e iteran siempre producen mejores resultados. Esto refleja lo que he visto en cada startup que he construido o asesorado. Los equipos que ganan son los que ponen algo en manos de los usuarios lo más rápido posible, y luego lo mejoran basándose en feedback real.

La mentalidad de fundador

El módulo se llama "Developer to CTO", pero lo que realmente enseño es la mentalidad de fundador. No todo el mundo montará una empresa. Pero todo el mundo se beneficia de pensar como alguien que tiene que entregar un producto, servir a clientes, gestionar costes y hacer crecer un equipo.

En Kamina.io, mi estudio de consultoría, trabajo con más de 40 equipos en toda Europa. Los ingenieros que destacan nunca son los que tienen el conocimiento técnico más profundo. Son los que entienden por qué están construyendo lo que construyen. Hacen preguntas sobre el usuario. Cuestionan los requisitos que no tienen sentido. Piensan en la mantenibilidad porque saben que alguien, quizá ellos mismos, tendrá que convivir con ese código durante años.

Esto es lo que intento inculcar a mis estudiantes. La competencia técnica es la base. Es lo que te hace entrar en la sala. Lo que determina tu trayectoria después de eso es tu capacidad de pensar más allá del código.

La lección más dura

La lección más dura que enseño trata sobre los compromisos. No los compromisos técnicos, esos son relativamente sencillos, sino los humanos.

Como CTO, tomarás decisiones que frustran a tu equipo. Elegirás la solución aburrida y fiable en lugar de la nueva y emocionante. Priorizarás pagar deuda técnica por encima de construir la funcionalidad que tu mejor ingeniero quiere con pasión. Dirás no a alguien que respetas porque el negocio necesita otra cosa ahora mismo.

Fui CTO en OneRagtime, gestionando un equipo en Barcelona mientras el negocio operaba por toda Europa. Tenía que decidir qué construíamos, qué retrasábamos y qué eliminábamos por completo. Esas decisiones nunca eran puramente técnicas. Implicaban personas, expectativas y relaciones.

Los estudiantes esperan que el rol de CTO consista en tomar las grandes decisiones técnicas. En parte sí. Pero sobre todo consiste en tomar las decisiones que nadie más quiere tomar, y hacerlo de una forma que mantenga al equipo motivado y alineado.

Por qué sigo enseñando

Sigo enseñando porque me hace mejor en mi trabajo diario. Cada cohorte de estudiantes me obliga a reexaminar mis suposiciones. Hacen preguntas que no había considerado. Cuestionan patrones que daba por sentados.

En Consentio, dirijo un equipo de diez ingenieros. Los marcos que uso para explicar conceptos a los estudiantes son los mismos que uso para alinear a mi equipo en la dirección técnica. Si puedo hacer que un estudiante de 22 años en Barcelona entienda por qué diseñamos los sistemas de cierta manera, puedo hacer que cualquiera lo entienda.

Enseñar es el mejor bucle de feedback que he encontrado. Fuerza la claridad. Y la claridad es la habilidad más infravalorada en el liderazgo de ingeniería.