Hay un momento, a mitad de El método NVIDIA de Tae Kim, en el que me descubrí subrayando como si tuviera veinte años y estuviera preparando un examen. No era por una frase ingeniosa ni por una anécdota heroica. Era por algo más pedestre: la descripción de un equipo que elige conscientemente el largo plazo, sabiendo que durante meses —o años— va a doler. Me sonó demasiado familiar: inversión con retorno diferido, discusiones incómodas en los comités, pequeñas renuncias que no tienen glamour… Ese “dolor organizado” es, para mí, el corazón del libro.
No escribo esto para ensalzar a NVIDIA ni para jugar al “copycat” industrial desde la barrera. Lo escribo porque llevo años intentando que mis propios proyectos —Foxize, DevsHealth, mis clases, incluso mi blog— se muevan de los fuegos artificiales a la ventaja que permanece. Y el libro me ha dado un lenguaje (y una lista corta de hábitos) que explica mejor por qué algunas cosas nos han funcionado… y por qué otras no.
La escena del trimestre
Empiezo por una escena recurrente. Entra un correo: “¿Cómo vamos de objetivos? Faltan X para cerrar el trimestre.” En ese momento, todo empuja hacia lo urgente. Nadie es inmune. He estado en esa conversación suficientes veces como para reconocer el patrón: la tentación de aparcar los proyectos incómodos (los que no lucen en el dashboard), rebajar un poco el nivel de exigencia en el producto, enchufar una funcionalidad que pide un cliente grande aunque sepas que te aleja de la arquitectura que quieres. Y sí, a veces cedes. Otras te plantas y decides proteger el 15–20% del tiempo y presupuesto para lo que no rinde hoy, pero te hará más rápido y más inevitable mañana.
El libro te recuerda —sin grandes fuegos— que en NVIDIA ese porcentaje existió durante años. Nadie se enamoró de CUDA el primer día. Nadie pedía GPUs programables con devoción litúrgica. Pero alguien tuvo la paciencia y la terquedad de construir un stack entero, pieza a pieza, mientras sonaban tambores de “¿y esto para qué?”. Me veo ahí: salvando las distancias, he aprendido que si una decisión no molesta a corto, seguramente es postureo. Si molesta, si te hace justificarte, probablemente estás en algo real.
Mi “CUDA” (y la tuya)
La tentación cuando se habla de CUDA es traducirlo a “software que escala”. Es cierto, pero insuficiente. CUDA es, sobre todo, una capa que convierte la capacidad técnica en plataforma: documentación, librerías, comunidad, cursos, soporte, foros, ejemplos, tooling. Es decir, un camino amable para que otros se suban y para que les cueste bajarse.
En mi día a día, la pregunta práctica es: ¿cuál es mi equivalente de CUDA? En educación corporativa, no es un chip, es andamiaje pedagógico + datos + agentes. Una taxonomía común para contenidos, un diagnóstico inicial que no sea decorativo, un circuito de práctica y feedback que cierre ciclos, y una capa de agentes que acompañe sin distraer. Cuando esto está bien armado, tu oferta deja de ser “un curso más” y se convierte en un sistema que aprende con el uso. Y cuando no, haces lo que todos: más horas de vídeo, más “motivación”, más PowerPoints. Esa es la diferencia entre ser plataforma y ser catálogo.
Me he pillado más de una vez intentando añadir features para ganar una venta rápida. Y sí, a veces lo haces. Pero cuando tu “CUDA” está clara, la mitad de las decisiones difíciles se vuelven triviales: ¿esto refuerza el andamiaje y acelera el circuito de aprendizaje? Sí: pasa. No: muere con honores.
Full-stack donde duele
Otra lección del libro —menos vistosa que las gráficas de ingresos— es la integración obstinada: hardware, drivers, bibliotecas, SDKs, documentación, soporte. No por estética, por defensa competitiva. Ese control de los bordes del producto es lo que te da velocidad real y feedback de calidad.
Traduzco de nuevo. No puedo —ni quiero— ser full-stack en todo. Pero sí en los puntos donde hoy sufre el cliente. El onboarding, por ejemplo. O la integración de datos. O la compatibilidad con el LMS del cliente, que no es el nuestro. O la seguridad (y el susto cuando alguien en legal te pide garantías con letra pequeña). En esos bordes, externalizar sin criterio es renunciar a aprender. Te quita dolores… y te quita músculo.
Recuerdo una migración de contenidos que prometía ahorrarnos semanas. A la cuarta llamada de soporte entendí que cada minuto ahorrado era un aprendizaje perdido. Volvimos a casa, rehicimos el pipeline, y los siguientes proyectos salieron en la mitad de tiempo. No fue épico. Fue aburrido. Pero ahí empezó a nacer nuestra ventaja.
La cultura que no queda bien en LinkedIn
El libro describe una cultura que no te van a aplaudir en una charla motivacional: estándares altos, revisión técnica sin anestesia, honestidad en el post-mortem. La tentación es romantizarlo. Yo prefiero el matiz: no se trata de glorificar el sufrimiento, sino de tolerar la incomodidad sostenida. Reescribir documentación que nadie lee, limpiar deudas técnicas que no salen en el dossier comercial, matar una funcionalidad que gusta porque entorpece el camino.
He estado en reuniones donde he sido la persona pesada que dice “esto no está para entregar” cuando todo el mundo quiere enviar ya. Y he sido también el que ha cedido por cansancio. El aprendizaje, para mí, es ritualizar la exigencia: post-mortems de verdad (con hechos, no con excusas), demos internas que enseñan lo que funciona y lo que no, checklists que obligan a pasar por el barro antes del “release”. Cuando institucionalizas la fricción sana, dejas de depender del héroe del día.
Elegir a los clientes como si fueran socios (porque lo son)
Esto me ha costado años. Los clientes definen más tu producto que tus slides. Si eliges a los equivocados, te arrastran a un roadmap ornamental. Si eliges a los correctos, te obligan a subir el nivel. NVIDIA cocreó con early adopters que empujaban: investigadores, hyperscalers, studios. No era “orientación al cliente” de buzón de sugerencias, era co-diseño con quien te aprieta donde duele.
En mi experiencia, esto se resume en un principio operativo: elige a tus clientes con el mismo rigor con el que contratas. Pregunta qué les duele de verdad, qué renunciarían a tener si les diera una ventaja real, y qué plazos están dispuestos a aceptar para construir algo que merezca la pena. A veces la venta rápida mata la empresa lenta.
Cadena de suministro: el backstage decide
Una de las cosas más injustas del éxito es que parece fácil retrospectivamente. “Claro, estaban en el sitio y momento adecuados”. Lo que no se ve es el trabajo de backstage: capacidad reservada, alianzas con proveedores, procesos que no hacen saltar titulares pero que evitan incendios. NVIDIA no “tuvo suerte” con la ola de la IA; estaba colocada.
Mi versión cotidiana de esto es bastante menos glamourosa: redundancia, SLAs claros, runbooks para incidentes, pruebas de backup que de verdad se ejecutan. Cuando te llama un cliente porque su auditoría pide certezas, no puedes improvisar seguridad. Y cuando llega un pico de demanda, o entregas o desapareces en silencio.
Europa, el riesgo y el reloj
Aquí entra un tema que me toca: nuestro ecosistema europeo. Queremos resultados de primer nivel con culturas que penalizan el riesgo y presupuestos que se cierran cada trimestre. Nos falta la incomodidad organizada del largo plazo. La posición fácil es culpar a los políticos, a los mercados o a los fondos. La difícil —y la útil— es empezar por casa: decidir qué porcentaje proteges para construir infraestructuras cognitivas propias, qué alianzas de verdad suman, y qué “prioridades” son una coartada para no elegir.
Me lo repito a mí mismo: si no duele en algo hoy, probablemente no estás construyendo nada que importe mañana.
Cinco movimientos que sí puedes copiar (sin disfrazarte de NVIDIA)
- Escribe tu “CUDA”.
No es un documento para el cajón. Es la definición pública de tu capa inevitable: API, taxonomía, proceso, tooling, guías, ejemplos. Cuando lo escribes bien, deja de haber discusiones abstractas: o encaja o no encaja. - Blinda el 15–20% para el largo plazo.
Ponle nombre y calendario. Hazlo visible. Y defiende ese espacio con la misma energía con la que defiendes una gran cuenta. Ese porcentaje financia tus órdenes de magnitud futuros. - Integra donde duele hoy.
Onboarding, datos, seguridad, soporte, documentación. Los bordes son tu marca. No puedes ser full-stack en todo, pero sí en los tres rozamientos que definen tu experiencia. - Ritualiza el post-mortem y la demo incómoda.
Una hora cada dos semanas. Sin reproches personales. ¿Qué falló? ¿Qué aprendimos? ¿Qué cambia mañana? Las primeras duelen. Luego se vuelven un alivio. - Construye capacidad antes de que “haga falta”.
Procesos, acuerdos, playbooks, métricas. No esperes al pico de demanda para aprender a escalar. Cuando llegue, es tarde.
Lo que me llevo a mi trabajo (y a mis clases)
Cuando pienso en cómo aplicar esto en Foxize, la traducción es directa: plataformas, no proyectos. Significa que un programa no es un paquete de vídeos, sino un circuito vivo: diagnóstico → práctica → feedback → transferencia al puesto. Significa que nuestros agentes no son fuegos artificiales de IA, sino pegamento que acompaña el aprendizaje real. Significa, también, que gobernamos nuestros datos con cabeza: soberanía del conocimiento no es encerrarse; es decidir con quién compartes, cómo y para qué.
En clase, el método se vuelve aún más humano: que el alumno no salga con apuntes bonitos, sino con criterio. Que sepa cuándo decir “no” a una funcionalidad que distrae, cómo leer una métrica que cuenta la película y no el tráiler, y cómo gestionar la incomodidad de mejorar lo aburrido. Les insisto: el atajo de la demo brillante dura un día; el pegamento que hace que algo funcione sin ti dura años.
Y en mi cuaderno personal —esa mezcla rara de blog, notas y listas de tareas— me quedan cinco preguntas para el lunes:
- ¿Está escrita y compartida mi “capa CUDA” o sigue dentro de mi cabeza?
- ¿Qué porcentaje fijo reservo esta semana al largo plazo y quién lo protege de mí mismo?
- ¿En qué tres fricciones voy a ser full-stack durante este trimestre?
- ¿Cuándo es el próximo post-mortem y qué ritual lo hará sincero?
- ¿Qué capacidad voy a construir antes de que alguien me la exija?
Epílogo sin épica
No necesitamos ser NVIDIA —ni podemos— para practicar su método. Basta con menos ansiedad de trimestre, más plataformas y la valentía de mejorar lo aburrido. Lo demás, lo que sale en las keynotes, llega después. Y suele llegar de golpe, como si fuera suerte.
A veces escribo estas cosas desde una mesa llena de subrayados y otras desde una cocina con olor a café y un perro reclamando paseo. En ambos sitios la lección es la misma: cuando el mundo pida lo tuyo, que te pille colocado. Con tu “CUDA” escrita, tus bordes bajo control, tus clientes elegidos y tu músculo hecho en silencio. Lo espectacular, ya vendrá. Lo importante se cocina antes. Y no sale en el vídeo resumen.