Mal Liderazgo Ralentiza Desarrollo Juegos 2025
Ninguna herramienta—IA o de otro tipo—puede acelerar el desarrollo de juegos si los líderes no están a la altura. En septiembre, GameDeveloper publicó una historia preguntando a desarrolladores sobre las razones reales por las que los ciclos de desarrollo de juegos se han vuelto más largos durante la última década. Después de la publicación, escucharon de un número sorprendente de lectores que preguntaron “por qué tu historia no dice nada sobre mal liderazgo”.
Por qué nadie mencionó el liderazgo inicialmente
El autor de GameDeveloper admite: no pude incluir ese tema porque… bueno… nadie de los entrevistados realmente lo mencionó.
También es difícil definir “mal liderazgo.” Malos hábitos en un estudio pueden ser saludables en otro. Esa es una lección que aprendieron hablando con otra ronda de desarrolladores durante el último mes, preguntándoles cómo han visto que el mal liderazgo ralentiza los plazos de desarrollo.
Los seis veteranos de la industria que consultaron describieron varios escenarios de pesadilla que alargaron y a veces condenaron el desarrollo de juegos de alto perfil (algunos solicitaron anonimato para hablar libremente sobre sus experiencias sin temor a represalias).
Sus experiencias muestran por qué las afirmaciones de que la IA generativa—o cualquier pieza de tecnología—acelerará el desarrollo de juegos están perdiendo el punto. Puedes construir el auto de carreras más rápido del mundo, pero si el dueño del equipo sigue moviendo mecánicos, ingenieros y pilotos de un lado a otro, no hay forma de que destaque del resto.
Los 7 comportamientos clave de líderes que ralentizan desarrollo
GameDeveloper identificó siete rasgos de alto nivel agrupando múltiples conversaciones con desarrolladores:
1. No entender las realidades del desarrollo de juegos
Ejemplos concretos:
- Aprobar contenido y luego descartarlo
- Pedir características sin entender o direccionar cómo implementarlas
- Necesitar ver material costoso y pulido temprano en el desarrollo para tomar decisiones
- Malas habilidades de gestión de proyectos, emitiendo plazos irreales y sin tener en cuenta dependencias departamentales
Caso documentado: El rigger 3D Sol Brennan describió líderes experimentados que decidieron saltarse el paso de “grey-boxing” del diseño de niveles y saltar directo a la producción de arte, sin reconocer cuánto de ese trabajo necesitaría rehacerse cuando viniera un cambio necesario al diseño del nivel.
2. Falta de confianza en los empleados
Ejemplos concretos:
- Requerir aprobación de demasiados líderes
- Ignorar cuando los trabajadores dicen que una tarea puede o no puede hacerse
- Despedir o tomar represalias contra colegas que hablan
- Ignorar advertencias del equipo de QA sobre bugs que podrían tener consecuencias dramáticas
Caso documentado: Un escritor anónimo de juegos describió un proyecto triple-A donde cada departamento necesitaba aprobación no solo de los líderes del departamento, sino de líderes de departamentos que tenían poca o ninguna experiencia en el trabajo que estaban revisando. Cuando estos líderes no podían llegar a un consenso, llevaba a semanas de trabajo colgando en el limbo.
3. Tratar a los desarrolladores como intercambiables
Ejemplos concretos:
- Esperar que los desarrolladores sean expertos en géneros en los que nunca han trabajado antes
- No reconocer que los desarrolladores que dejan el estudio se llevan conocimiento institucional clave
- Asumir que otros trabajadores pueden reemplazar fácilmente a quienes se van
Caso documentado: El productor Masao Kobayashi observó que los líderes de estudio aprobarían juegos o cambiarían de dirección únicamente basándose en lo que fue comercialmente exitoso en el último trimestre. Desarrolladores acostumbrados a plataformas familiares no pueden pivotar rápidamente a hacer un MOBA tipo League of Legends. Los desarrolladores de MOBA pueden tener dificultades para entender “hero shooters” en tercera persona.
4. Toma de decisiones lenta
Ejemplos concretos:
- Nuevamente, requerir aprobación de demasiados líderes
- Líderes enfocándose excesivamente en puntos específicos de desarrollo y no ofreciendo dirección en características que afectan a múltiples equipos
- No tomar decisiones durante semanas o meses por razones incomprensibles
Caso documentado: Un desarrollador anónimo recordó su experiencia haciendo juegos en los años 2000 donde, por razones inexplicables, su líder de departamento era incapaz de tomar decisiones. Si el equipo presentaba tres opciones—todas igualmente ejecutables—a veces les tomaba meses hacer una llamada final. ¿Qué estaba haciendo este líder mientras su equipo esperaba frustrado? Aparentemente obsesionándose con detalles menores de la historia del juego.
5. Proporcionar poco o ningún feedback útil al criticar trabajo
Ejemplos concretos:
- Publishers rechazando milestone builds con poca explicación
- Líderes de equipo criticando trabajo con poca más dirección que “hazlo más cool”
Caso documentado: El diseñador de niveles anónimo recordó a su compañero resumiendo el feedback vacuo que ambos recibían de su líder: “Otro diseñador lo describió como ‘consígueme una roca. No esa, una mejor roca.’ Simplemente harían eso hasta que string lock nos forzara a enviar lo que fuera la última iteración.”
Caso público: Los lectores interesados en un caso de estudio claro deberían revisar el documental de Double Fine y Two Player Productions sobre la creación de Psychonauts 2. Destaca cómo el feedback poco claro del fundador del estudio Tim Schafer y el entonces líder de proyecto Zak McClendon frustró a los empleados y dejó a algunos diseñadores trabajando en I+D mientras el juego avanzaba hacia una build Alpha.
6. Exigir cambios repentinos en dirección o nuevas características
Ejemplos concretos:
- La clásica anécdota de “nuestro director creativo jugó X juego durante el fin de semana”
- Políticas de crunch vagas causadas por negarse a reconocer plazos cambiantes
Caso documentado: Los diseñadores de juegos todavía bromean sobre el “fenómeno Dark Souls”, donde líderes creativos en desarrollo de juegos se van a casa el fin de semana, juegan un juego (merecidamente) popular como Dark Souls, Bloodborne o Elden Ring, y regresan a la oficina con directivas repentinas para nuevas características inspiradas en estos títulos. El escritor anónimo señaló que estos cambios a veces suceden después de que el director del juego ve una película o programa de TV muy comentado también.
7. Políticas de crunch vagas
Ejemplos concretos:
- Prometer que el equipo “no hace crunch”, pero establecer plazos que requieren horas extras
- Establecer políticas de empresa que ponen un límite estricto en el tiempo de trabajo de trabajadores por hora—llevándolos a hacer trabajo no remunerado fuera del horario
Caso documentado: Algunos desarrolladores describieron cómo las políticas de “no crunch” comenzaron a generar conflicto entre desarrolladores cuando algunos trabajadores eran vigilantes sobre sus horas de trabajo mientras otros se extendían a horas extras. No solo vieron a algunos colegas expresar resentimiento por su decisión de irse a tiempo, sintieron presión del liderazgo para hacer crunch de todos modos a pesar de la política declarada.
Las empresas que emplean trabajadores por hora pueden crear una versión codificada de esto limitando el número de horas trabajables. Si los líderes del equipo establecen objetivos irreales, pero los empleados solo pueden poner tantas horas en el reloj, es inevitable que comiencen a hacer trabajo no remunerado en su tiempo libre.
Los números del problema: QA ignorado y empleados intercambiables
La especialista en QA Rose Whitcomb recordó un proyecto donde los desarrolladores despriorizaron bugs centrados en personajes seleccionables menos populares. “El dev priorizó favoritos de la comunidad y los enfocaría mientras dirigía a QA a enfocarse en ellos a pesar de los problemas acumulándose para los otros,” dijo. Algunos de estos bugs provocaban crashes duros cuando personajes poco jugados se emparejaban juntos.
Luego el juego se lanzó—después de que esos personajes poco amados habían sido mejorados y era más probable que fueran seleccionados para misiones. El equipo perdió tiempo precioso haciendo hotfix de un problema que podría haberse solucionado meses antes.
Kobayashi también observó el fenómeno de “problemas previamente resueltos convirtiéndose en problemas nuevos” cuando los empleados se van: “Con los despidos masivos y la mayor dependencia de socios de co-desarrollo externos, estos problemas previamente resueltos se convirtieron en problemas novedosos que costaron más y tomaron más tiempo resolver.”
Cuando el mal liderazgo es estructural vs individual
Una cita del escritor Robert Caro resonó en la cabeza del autor mientras escuchaba estas diferentes historias: “El poder revela.” Es una frase más compleja que “el poder corrompe”, que implica que cualquiera en liderazgo inevitablemente se volverá dañino y egoísta. “El poder revela” nos pide definir no solo las acciones de un líder, sino la naturaleza de la autoridad que poseen.
No hay una forma de acelerar el desarrollo de juegos. Y no hay una forma de mejorar el liderazgo en toda la industria de videojuegos. A veces educar sobre cuánto poder puede tener un pequeño grupo de individuos sobre el proyecto despejará bloqueadores de mitad de desarrollo. En otras ocasiones, los líderes que planifican temprano y se adhieren a decisiones tomadas temprano en el proceso, cambiando de rumbo solo cuando sea necesario, pueden convertir estudios en potencias de creación de juegos.
Cambia lo que significa “poder” en el desarrollo de juegos, y puedes cambiar lo que “revela” sobre quienes lo tienen.
Pero hay quienes en liderazgo que, cuando se les da poder, siempre revelarán ser indignos de él. Podrían abusar verbalmente de colegas, excluir a miembros clave del equipo de reuniones, o enfrentar a trabajadores entre sí. En el peor de los casos, podrían unirse a las filas de aquellos acusados de acosar o discriminar a desarrolladores, solo manteniendo su posición hasta que alguna exposición arroje luz sobre sus acciones.
Esta es la contradicción en el corazón de las luchas de liderazgo de la industria del juego. La reforma estructural es necesaria. Pero los malos líderes a veces se cuelan a través de cualquier intento de cambio positivo, manteniendo el poder gracias a relaciones cercanas con personas más arriba en la cadena alimentaria.
Las lecciones para la industria
Lección 1: La IA no puede arreglar esto. Ninguna herramienta puede acelerar el desarrollo si los líderes no escuchan a quienes realmente hacen juegos.
Lección 2: El feedback vago es tan malo como ningún feedback. “Hazlo más cool” o “consígueme una mejor roca” no son direcciones ejecutables.
Lección 3: La aprobación de múltiples líderes crea cuellos de botella masivos. Cuando cada departamento necesita aprobación de líderes sin experiencia en ese trabajo, semanas de trabajo cuelgan en el limbo.
Lección 4: Los desarrolladores no son intercambiables. Un dev de plataformas no puede pivotar instantáneamente a hacer MOBAs. El conocimiento institucional se va cuando los empleados se van.
Lección 5: “No hacemos crunch” sin cronogramas realistas es una mentira. Si estableces deadlines imposibles con política de no-crunch, solo estás empujando trabajo no remunerado fuera del horario.
Lección 6: QA no es desechable. Ignorar advertencias de QA sobre crashes porque afectan personajes “poco populares” cuesta tiempo precioso en hotfixes post-lanzamiento.
Lección 7: Las decisiones lentas tienen efectos downstream masivos. Un líder que toma meses decidiendo entre tres opciones igualmente viables paraliza a todo el equipo.
¿Tu estudio está luchando con cronogramas que se alargan inexplicablemente? Antes de culpar a la tecnología o la complejidad de los juegos modernos, examina estos siete comportamientos. Si reconoces tres o más, el problema no es tecnológico—es de liderazgo. La buena noticia: el liderazgo puede cambiar más rápido que reconstruir tu tech stack. La mala noticia: requiere que quienes tienen poder admitan que son parte del problema. Hablemos sobre cómo identificar y corregir estos patrones antes de que cuesten años de desarrollo.
Fuente: GameDeveloper - How poor leadership slows down game development (Nov 2025)