El 24 de junio de 2026, John Carmack publicó un largo hilo en X. Era una reflexión inusualmente sincera sobre un error de gestión, tranquila y concreta, radicalmente distinta de sus habituales análisis de gráficos o tecnología VR. El hilo terminaba con dos palabras sobrias: «Sorry, Sandy», una disculpa que había permanecido en silencio durante décadas en la historia de id Software. Para entonces, la publicación ya había superado el millón de visualizaciones, y la discusión relacionada en Hacker News había acumulado 468 votos y 235 comentarios en medio día. Más allá de la repercusión, el hilo tocaba una cuestión que trasciende la historia de los videojuegos: cuando un genio técnico es también el núcleo de la toma de decisiones del equipo, ¿dónde está su punto ciego?
El autor no ha trabajado en la industria del videojuego ni ha gestionado equipos de ingeniería. El siguiente análisis se basa completamente en las declaraciones públicas de Carmack, los registros de entrevistas de Sandy Petersen a lo largo de los años y las perspectivas de gestión de ingeniería surgidas en discusiones de comunidades como HN. Se trata de un examen neutral de los límites del liderazgo técnico.
Qué decía exactamente ese hilo
La reflexión de Carmack enumeraba cuatro puntos concretos.
El primero fue la ambición excesiva en las decisiones técnicas. Quake introdujo en 1996 entornos completos 6DOF y modelos de personajes tridimensionales, algo revolucionario en su momento. Pero ahora cree que se podría haber implementado el multijugador y el sistema de mods sobre un motor «Doom++», permitiendo a los diseñadores de niveles trabajar sobre una base más estable, sin sufrir los constantes «rug-pulling» (tirones de alfombra) de los cambios en la tecnología subyacente. El verdadero 3D completo podría haberse reservado para el siguiente título.
El segundo fue la pérdida de control sobre la intensidad del trabajo. Admite que «presionó a todo el mundo demasiado», sin comprender que una empresa en maduración necesita más margen de maniobra, y que «mantener la intensidad de una startup de forma continua acaba agotando a la gente». Fue durante el desarrollo de Quake cuando realmente chocó contra el techo de su capacidad personal: incluso trabajando al límite de lo humanamente posible, seguía sin cumplir sus propios plazos.
El tercero fueron los errores de diseño en la estructura accionarial y las cláusulas de adquisición. El equipo fundador quería asegurarse de que la propiedad estuviera solo en manos de quienes «estaban dejándose la piel por el proyecto actual», pero visto en retrospectiva, un mecanismo de vesting al estilo de Silicon Valley habría sido una opción mejor.
El cuarto es el más delicado. Carmack hizo una declaración expresa: exigir que los diseñadores de niveles también poseyeran una gran capacidad artística visual es algo sobre lo que «no acepto críticas». Explicó que John Romero ya había establecido esa expectativa desde el principio. El verdadero problema fue no haber creado antes un mecanismo de «colaboración por parejas entre artistas y diseñadores». Pero en aquel momento existían luchas internas entre los diseñadores, y quienes dominaban tanto el diseño como el apartado visual se complacían en menospreciar a los compañeros que no podían.
Y luego, las tres palabras finales: «Sorry, Sandy.»
Quién es Sandy Petersen y por qué «Sorry, Sandy» importa
Sandy Petersen se incorporó a id Software en 1993, apenas diez semanas antes del lanzamiento oficial de Doom. En ese breve lapso, construyó 19 de los 27 niveles de Doom, de los cuales menos de la mitad se basaban en los esqueletos dejados por el anterior diseñador, Tom Hall. Después, en los 32 niveles de Doom II, contribuyó con 17 más.
Los niveles de Petersen tienen una identidad reconocible. En sus propias palabras, sus mapas «normalmente no son los más bonitos», pero contienen una gran cantidad de coreografías de encuentros meticulosamente diseñadas: filas de explosivos que conducen hacia hordas de monstruos, piscinas flotando en el aire, narrativa ambiental que insinúa el peligro que aguarda. Su diseño estaba enraizado en años de experiencia en RPG de mesa, y primaba la «jugabilidad» sobre la «visualidad».
El problema fue que, con la introducción de la tecnología 3D y la creciente complejidad de los sistemas de materiales e iluminación, los requisitos visuales que id Software exigía a los diseñadores de niveles se dispararon. Petersen no poseía habilidades profesionales de arte, y sus mapas empezaron a parecer «poco atractivos» según los estándares estéticos de la era Quake. Al mismo tiempo, surgieron figuras como Tim Willits, que combinaban capacidad artística y de diseño, y se formó una jerarquía implícita dentro del equipo: los que sabían dibujar menospreciaban a los que solo sabían diseñar.
En el propio relato de Sandy Petersen, durante el desarrollo de Quake existió una grave política de oficina dentro del equipo. En múltiples entrevistas afirmó que la figura central que provocó la división del equipo no fue Carmack, sino «alguien a quien me niego a nombrar», interpretado por la comunidad generalmente como Tim Willits. Petersen dejó id Software en 1997 y se unió a Ensemble Studios. Por las mismas fechas o poco antes, también se marcharon John Romero y varios otros miembros clave: según el recuento del usuario de HN jpgvm, de las aproximadamente 11-12 personas del equipo de Quake, unas 7 terminaron marchándose.
Y en el hilo original que desencadenó todo el debate, el propio Sandy Petersen escribió una frase, parcialmente colapsada por la interfaz de X: «Si mi deducción es correcta —Quake destruyó id Software— ¿mereció la pena? Yo diría que absolutamente sí. Los juegos son más importantes que las empresas de juegos, y Quake es un hito icónico en el mundo del videojuego.”
Varias perspectivas clave de la discusión en la comunidad
Los comentarios en HN no fueron un coro unánime de emoción ni de condena; lo más interesante fue la tensión que revelaban.
El usuario georgemcbay comentó que las lecciones técnicas y de gestión que Carmack exponía con franqueza tenían valor, por supuesto, pero lo que más apreciaba era la «disculpa clara, directa y empática» del final. Dijo que Carmack podría haber usado perfectamente el argumento de «tenía solo 24 o 25 años», una explicación perfectamente aceptable para la opinión pública, pero eligió disculparse directamente. Eso pesa más que cualquier justificación.
El usuario hiddencost hizo una lectura completamente opuesta, considerando que todo el hilo era en esencia «un insulto envuelto en un gesto profesional»: Carmack estaba diciendo públicamente que «Sandy es un diseñador malo sin sentido estético visual», y resultaba «bastante incómodo y cruel de leer».
Estas dos lecturas revelan una tensión más profunda: Carmack, al aceptar los límites de su responsabilidad en la reflexión, se niega simultáneamente a asumir la culpa por una decisión concreta. Su lógica es que el estándar estético lo estableció Romero al principio, que era un consenso a nivel de empresa, no un error personal suyo. Pero como núcleo técnico y uno de los decisores de la empresa, ¿cubre esta postura de «responsabilidad parcial» las obligaciones propias del rol de decisor? Esta pregunta no tiene una respuesta estándar, pero merece que todo líder técnico se la formule ante su propio momento «Sorry, Sandy».
El usuario CamperBob2 defendió la ambición técnica de Carmack: «El argumento de ‘se podría haber hecho un Doom++’ ignora el hecho de que todo el mundo anhelaba el siguiente salto. El motor Build de Ken Silverman (Duke Nukem 3D) ya estaba en camino y salió unos seis meses antes que Quake. Acortar el calendario de Quake habría puesto a ambos productos en competencia directa, perjudicando a los dos. Ejercer la superioridad técnica era precisamente el deber de Carmack, y lo cumplió; no debería disculparse ni dudar de sí mismo a posteriori.”
El usuario tombert citó la narrativa del libro «Masters of Doom» y dejó esta impresión: «John Carmack es una persona extremadamente inteligente y al mismo tiempo un posible capullo gigantesco.» Dijo que si él hubiera estado en el equipo de desarrollo de Quake, «probablemente habría mandado a Carmack al infierno a medio camino», aunque Quake sigue siendo su FPS clásico favorito.
El comentario del usuario grim_io fue de una sola frase, pero quizás el resumen más preciso de toda la discusión: «Quizás la excelencia extrema simplemente no es sostenible.»
La ortogonalidad entre capacidad técnica y capacidad de gestión
Desde la perspectiva de la gestión de ingeniería, lo más revelador del hilo de Carmack es una cuestión más estructural: la capacidad técnica y la capacidad de gestión son ortogonales.
La calidad de las decisiones técnicas de Carmack está fuera de toda duda: el pipeline de renderizado de Quake, la máquina virtual QuakeC, la arquitectura de red client-server, cada una de ellas definió el estándar de la industria en su momento. Pero cuando la perspectiva pasa de «cómo construir el sistema óptimo» a «cómo construir y mantener el equipo óptimo», el mismo marco de juicio puede fallar. Los problemas técnicos tienen un espacio de soluciones definido, se pueden enumerar, evaluar con benchmarks y demostrar; los problemas humanos no.
Concretamente, en el caso de id Software, se pueden extraer varias observaciones a nivel de gestión:
Primero, la trampa de la preferencia por el «talento omnicompetente». En los inicios, el equipo era pequeño y cada persona desempeñaba múltiples roles: el propio Romero escribía código, hacía niveles y tomaba decisiones de diseño. Este modelo funcionaba bien en un equipo de seis personas, pero cuando el equipo creció hasta la docena y las exigencias técnicas se dispararon, mantener que «los diseñadores de niveles deben tener también capacidad artística» dejó de ser elitismo para convertirse en un estrechamiento excesivo del embudo de selección de talento. No solo excluía a quienes no cumplían el estándar, sino potencialmente a quienes eran extraordinarios en una única dimensión.
Segundo, el riesgo estructural del modelo del genio único. El éxito de id Software en la era Doom se basó en gran medida en la estructura de doble núcleo: el motor técnico de Carmack + el impulso de diseño de Romero. Pero cuando el techo de la capacidad personal del genio se alcanza (el propio Carmack admite que durante el desarrollo de Quake trabajó «tan duro como humanamente posible hasta el límite»), el espacio de crecimiento del sistema se agota simultáneamente. Un genio individual puede retrasar la llegada de ese día, pero no puede eliminarlo.
Tercero, la ausencia del rol de mediador de conflictos. Carmack menciona en su hilo las «luchas internas» entre los diseñadores —quienes dominaban el apartado visual se complacían en menospreciar a los compañeros que no podían— pero al parecer nadie intervino para detener o mediar en ese comportamiento. En los equipos impulsados por la tecnología, la dirección (si es que existe) suele dar por sentado que «la producción es lo primero», considerando la fricción interpersonal como un problema secundario. Pero la fricción no resuelta acaba convirtiéndose en fuga de talento.
Estos tres problemas no son exclusivos de Carmack: el autor vio en los comentarios de HN una gran cantidad de ingenieros que se identificaban, considerando que historias similares de «líderes técnicos que no saben gestionar personas» se repiten una y otra vez en la industria. Solo que esta vez fue el protagonista quien lo escribió personalmente.
Declaración de humildad
Este artículo se basa completamente en el hilo público de Carmack, las entrevistas públicas de Sandy Petersen y las discusiones públicas en comunidades como HN. El autor no ha tenido contacto de primera mano con el funcionamiento interno de id Software, y todas las inferencias a nivel de gestión parten de materiales públicos, sin constituir un juicio definitivo sobre ninguna persona o empresa. El artículo ha utilizado herramientas de IA como apoyo en la organización y estructuración de materiales; el juicio central y la expresión escrita son obra humana.
El punto ciego de gestión del genio técnico no es un problema que deba ser eliminado: quizás sea simplemente el precio de cierto tipo de creatividad. La cuestión es si, como generación posterior, podemos verlo antes de que el precio se haya pagado.