Cuando la dirección siente que el equipo va lento

Tarde o temprano llega la misma frase, en algún comité, dicha con distintas palabras: ¿por qué el equipo de desarrollo va tan lento?

Es una sensación legítima. La dirección ve el mercado moverse, ve a la competencia lanzar, y no ve el producto avanzar al ritmo que espera. El instinto casi siempre es el mismo: más presión, más gente, más urgencia. Y ahí es donde la mayoría de las organizaciones se equivocan de diagnóstico.

El error de diagnóstico

Desarrollo no es un grifo que abres más fuerte. Es un sistema con capacidad escasa. Nueve mujeres embarazadas no hacen un bebé en un mes. Puedes añadir gente, puedes presionar, puedes exigir "más urgencia", y aun así el sistema tiene un límite de cuánto puede procesar bien a la vez. Meter más dentro de un sistema saturado no lo acelera: lo satura más, genera más contexto switching, más deuda, más incidentes. Frederick Brooks lo documentó hace décadas con el Mythical Man-Month y sigue siendo tan cierto como entonces.

Esto no significa que no haya palancas dentro del sistema (las hay, y las conozco bien porque las he tocado todas en 15 años liderando equipos): buenas prácticas de ingeniería, arquitectura que no colapsa bajo su propio peso, gente formada, herramientas correctas. Todo eso importa. Pero tiene rendimientos marginales decrecientes. Puedes optimizar el sistema un 20-30%. No vas a triplicar la velocidad optimizando cómo se procesa lo que entra.

El apalancamiento real está en otro sitio: qué decidimos que entra al sistema.

Las dos palancas reales

Todo problema de "lentitud" se puede separar en dos ejes:

Oferta (cómo procesamos): ingeniería, equipo, tecnología, formación.
Demanda (qué dejamos entrar): las apuestas de negocio y producto que comprometen esa capacidad escasa.

La mayoría de las organizaciones invierte toda su energía en la oferta y casi ninguna en la demanda. Contratan, reorganizan, cambian de metodología, y siguen sin preguntarse si las apuestas que están metiendo en el sistema tienen sentido de negocio. Ahí es donde he visto el mayor desperdicio de capacidad en mi carrera: no en malas líneas de código, sino en buenas líneas de código construyendo cosas que no debían construirse todavía, o que no debían construirse así.

Cuando la apuesta no tiene business case

En Creditas viví de cerca lo que significa establecer una operación desde cero en un mercado nuevo: contratar, formar equipos de alto rendimiento, y sobre todo, decidir qué construir primero cuando todo parece urgente. Con Creditas Store, Creditas Benefícios y Creditas Auto sobre la mesa, la disciplina no estaba en programar rápido, estaba en tener claridad de qué apuesta merecía capacidad de ingeniería y cuál no, con objetivos y OKRs que obligaban a justificar el porqué antes del cómo. Cuando esa disciplina existe, "ir lento" deja de ser el problema, porque lo que entra al sistema ya viene filtrado por sentido de negocio.

Cuando algo no escala y te atrapa

En Enterticket el reto era distinto: un producto legacy que necesitaba modernizarse y abrirse a mercados nuevos, sin parar el negocio. La tentación fácil ahí es la reescritura total, pasar meses o años "arreglándolo todo por dentro" mientras el negocio espera. Elegimos lo contrario: modernización evolutiva, arquitectura hexagonal y microservicios donde aportaban valor real, y foco en lanzar el nuevo portal de compra y la expansión a México con Product-Led Growth. La gobernanza de producto ahí fue la clave, decidir qué merecía inversión de arquitectura y qué no, en vez de quedar atrapados refactorizando indefinidamente algo que el negocio ya no necesitaba de esa forma.

Cuando el crecimiento acelerado exige filtrar, no solo ejecutar

En etapas de alto crecimiento, algo que viví de cerca en RD Station, todo se siente urgente al mismo tiempo. Ahí el riesgo no es la falta de ejecución, es la falta de filtro: cuando cualquier iniciativa parece razonable, el sistema se llena de apuestas mediocres compitiendo por la misma capacidad escasa. La cultura lean se demuestra justo ahí: medir antes de escalar, validar antes de comprometer meses de ingeniería, y usar Kanban no como decoración sino como forma real de hacer visible cuánto hay "en vuelo" a la vez, porque lo que no se ve, no se gestiona, y lo que no tiene límite de WIP, se acumula silenciosamente hasta que "todo va lento".

Lo que de verdad cambia la percepción de velocidad

Con esto en mente, la lista de lo que realmente mueve la aguja no es técnica en primer lugar, es de negocio, cultura y gobernanza:

Metas y objetivos claros: sin un objetivo de negocio nítido, cualquier iniciativa parece igual de urgente, y ahí se pierde la capacidad.
Buenas apuestas con business case: cada iniciativa grande debería justificar por qué merece capacidad de desarrollo antes de comprometerla, no después.
Pensamiento y valores lean: validar antes de escalar, medir antes de comprometer, matar rápido lo que no funciona.
Evidenciar el trabajo, Kanban: hacer visible cuánto hay en curso, dónde se atasca y cuánto cuesta cada cosa en capacidad real.
Ajustar la cultura: la velocidad percibida es también una cuestión de confianza y alineación, no solo de entrega.
Premiar a los buenos, despedir a los tóxicos: la capacidad escasa se destruye más rápido por una mala actitud que se tolera, que por una mala decisión técnica.
Formar al equipo: invertir en las personas es invertir en la única parte del sistema que mejora con el tiempo si se cuida.

Checklist práctico para la alta gestión

Antes de preguntar "¿por qué vamos lentos?", pregúntate esto:

1. ¿Toda apuesta grande tiene un business case explícito antes de comprometer capacidad de desarrollo?
2. ¿Sabemos, en cualquier momento, cuánto tenemos "en vuelo" a la vez (WIP)?
3. ¿Revisamos las apuestas en curso (no solo las nuevas) y matamos las que no están funcionando?
4. ¿Quién tiene autoridad real para decir que no a una iniciativa, y se usa esa autoridad?
5. ¿Estamos premiando a quien aporta y siendo honestos con quien no encaja en la cultura?
6. ¿Invertimos en formar al equipo, o solo en exigirle más?
7. ¿Medimos la capacidad de desarrollo como una restricción de negocio, y no como un fallo de ingeniería?

Si la mayoría de estas respuestas es "no", el problema nunca fue la velocidad del equipo. Fue lo que decidimos meter en un sistema que, por diseño, nunca iba a poder con todo a la vez.