Muchas de las lecturas recomendadas sobre Management ponen el foco en los factores racionales asociados a un proyecto, como el diseño de los flujos de trabajo o el diseño de tareas.
En la mayoría de estos casos, el enfoque más usado en la gestión de proyectos (y por consiguiente, en la gestión de equipo) se centra en los procesos, donde cada tarea es definida como un conjunto de reglas.
¿A qué se puede deber entonces este fracaso? Te invito a seguir leyendo ⬇️
Dicen los datos de Harvard Bussiness Review nos revela que el 73% de los proyectos de IT fracasan o se retrasan. ¿La razón? Nos hemos obsesionado con el código y los procesos, olvidando que quien teclea son personas con emociones.
Muchas veces nos obsesionamos con la parte racional de los proyectos: diseñar flujos de trabajo perfectos, definir tareas al milímetro y establecer reglas para todo. Sin embargo, los datos son tozudos. Harvard Business Review ya nos advirtió de que, bajo ese esquema rígido, la tasa de éxito en proyectos de IT se queda en un pobre 27%. Peor aún: uno de cada seis proyectos acaba costando el triple de lo previsto y se entrega con un retraso enorme.
¿Por qué fallamos tanto?
Porque seguimos empeñados en usar herramientas y teorías que idolatran la lógica y olvidan lo que de verdad mueve la aguja: las personas y sus emociones. Ahí es donde se juega la partida.
No renegamos de la metodología. Tener los plazos claros y entregar a tiempo es vital. Pero nuestra experiencia nos dice que eso es solo la base. La verdadera diferencia, nuestro ingrediente secreto si quieres llamarlo así, está en el liderazgo y en cómo gestionamos a la gente.
Si nos ponemos científicos, todo empieza en la amígdala cerebra (si quieres visualizarlo mejor, imagina una línea que entra por tus ojos y otra que entra por tus oídos. Donde se cruzan ambas líneas, en el interior del cerebro, ahí residen y son dos). Esa pequeña parte del cerebro es la que enciende las emociones y controla los impulsos. Es la sede del liderazgo primario y de la inteligencia emocional.
Sabemos que un equipo con ganas funciona mejor, la tarea del líder es conseguir esa chispa. Pero aquí surge la gran pregunta: si el líder debe motivar a todos... ¿quién motiva al líder?
No podemos dejar la motivación de todo el equipo en manos de unos pocos agotados. Igual que repartimos tareas, toca repartir el liderazgo. Necesitamos un liderazgo compartido. Y para eso, hay que cuidar a quienes guían el barco.
Para que un líder funcione, necesita cultivar cinco grandes áreas:
- Conocerse a sí mismo: Saber qué se le da bien y dónde cojea. Desde Gestión de Talento, nuestra labor es facilitarles ese espejo.
- Controlarse: Saber equilibrar la exigencia con la recompensa. No todo vale y tener esa balanza ajustada es obligatorio.
- Tener motor propio: El líder debe ser el primer convencido. Su liderazgo debe nacer de él, no ser una imposición externa.
- Ponerse en la piel del otro: La empatía no es solo entender cómo se siente el compañero, es detectar cuándo está listo para crecer.
- Moverse bien con la gente: Gestionar roces, impulsar cambios y unir fuerzas entre compañeros. En definitiva, ser quien inspira y guía.
Pero ojo, que el líder tenga estas cualidades de fábrica no basta. El día a día desgasta a cualquiera. Por eso, cualquier estrategia de personas debe incluir planes para recargar las pilas de estos perfiles.
¿Cómo lo hacemos en la práctica?
Primero, buscando a los líderes naturales. Jamás obligues a nadie a cargar con esa responsabilidad si no le nace.
Segundo, dándoles herramientas para verse con claridad. En Mobiliza usamos nuestras matrices de competencias y el sistema InProgress, que permite a cada uno saber dónde está y pulir esas capacidades que nos hacen crecer.
Y tercero, hablando claro. Nuestra cultura se basa en el feedback constante. Usamos foros y herramientas donde los referentes del equipo comparten sus visiones directamente con la dirección.
Al final, los procesos ayudan, claro. Pero la inteligencia emocional —esa capacidad para entender y gestionar lo que sentimos nosotros y los demás— es la pieza que separa un proyecto mediocre de un éxito rotundo.
Comments (2)
Log in to your Scrum Manager area to comment
Guest
26 Jan 2026 12:40Very interesting. Thank you for your contribution.
I would be interested to know which approaches or motivation techniques have given you the most positive results when leading change in IT teams, and whether you have identified the reasons behind that success.
Muy interesante. Gracias por el aporte.
Me interesaria saber que abordaje o tecnicas de motivacion son las que les han dado mas resultados positivos para liderar el cambio en equipos de IT y si han detectado las razones de ese triunfo.
Automatic translation · View original
Jorge Sánchez López ★★★
9 Feb 2026 09:22(Guest), Thanks for the question, and sorry for the delay, but your question needed time and long reasoning that I haven't been able to give it the attention it deserves.
In IT teams, what has worked best for us is not "motivation techniques" like inspiring slogans, but designing conditions so that motivation doesn't fade. In practice, what tends to have the biggest impact is this:
1- Purpose grounded in impact (not in epics)
Translate the change into: "what improves for the client / the business / the team itself" in 2–3 measurable outcomes.
Why it works: it reduces uncertainty and avoids the "this is management's whim" feeling.
2- Autonomy with clear limits (guardrails)
The team decides the "how" within constraints (security, compliance, deadlines, budget).
Why it works: real autonomy = real commitment. Excessive control = cynicism.
3- Small visible wins (short cadence)
Small deliveries, frequent demos, and explicit signaling of progress.
Why it works: motivation in IT is fueled by progress, not by promises.
4- Operational psychological safety
Simple rules: "in retros we talk about the system/process, not about culprits"; blameless postmortems; language of facts + data.
Why it works: if mistakes are punished, people hide information and the project becomes blind.
5- 1:1 feedback + specific recognition
Recognize concrete behaviors ("why this helped the team"), not generic "good job."
Why it works: it reinforces useful patterns and reduces invisible burnout.
6- Co-creating the change (not "we're just telling you")
Involve the team in the diagnosis and in the options (3 alternatives, trade-offs, explicit decision).
Why it works: resistance drops when people have agency and the process is seen as fair.
7- Align incentives and metrics
If you only measure velocity, you generate debt and theater. If you only measure compliance, you kill learning. Better: outcomes + quality + flow.
Why it works: people respond to the reward system, not to the speech.
** Typical reasons for "success" when it works: **
- Uncertainty is reduced (clarity about why and what for).
- The sense of control increases (autonomy).
- Professional identity is protected (respect for technical judgement).
- Real progress is visible (wins + visibility).
- Fear is removed (psychological safety).
If you want, tell me what kind of change it was (reorg, new stack, cloud, DevSecOps, Agile, downsizing, etc.) and I'll tell you which combination usually works best and which antipattern usually sabotages it (because there almost always is one).
(Invitado), Gracias por la pregunta. y disculpa la tardanza pero tu pregunta necesitaba un tiempo y un razomiento largo que no le he podido dedicar el tiempo que se merece.
En equipos IT, lo que mejor resultado nos ha dado no son “técnicas de motivación” tipo frase inspiradora, sino diseñar condiciones para que la motivación no se apague. En la práctica, lo que más impacto suele tener es esto:
1- Propósito aterrizado a impacto (no a épica)
Traducir el cambio a: “qué mejora para el cliente / el negocio / el propio equipo” en 2–3 outcomes medibles.
Por qué funciona: baja la incertidumbre y evita el “esto es capricho de dirección”.
2- Autonomía con límites claros (guardrails)
El equipo decide el “cómo” dentro de constraints (seguridad, compliance, fechas, presupuesto).
Por qué funciona: autonomía real = compromiso real. Control excesivo = cinismo.
3- Pequeñas victorias visibles (cadencia corta)
Entregas pequeñas, demo frecuente, y señalización explícita de avances.
Por qué funciona: la motivación en IT se alimenta de progreso, no de promesas.
4- Seguridad psicológica operativa
Reglas simples: “en retro hablamos de sistema/proceso, no de culpables”; blameless postmortems; lenguaje de hechos + datos.
Por qué funciona: si el error se castiga, la gente oculta información y el proyecto se vuelve ciego.
5- Feedback 1:1 + reconocimiento específico
Reconocer conductas concretas (“por qué esto ayudó al equipo”), no “buen trabajo” genérico.
Por qué funciona: refuerza patrones útiles y reduce el desgaste invisible.
6- Co-creación del cambio (no “os lo comunico”)
Involucrar al equipo en el diagnóstico y en las opciones (3 alternativas, trade-offs, decisión explícita).
Por qué funciona: la resistencia baja cuando hay agencia y se ve justicia en el proceso.
7- Alinear incentivos y métricas
Si mides solo velocidad, generas deuda y teatro. Si mides solo cumplimiento, matas aprendizaje. Mejor: outcomes + calidad + flujo.
Por qué funciona: la gente responde al sistema de recompensas, no al discurso.
** Razones típicas del “triunfo” cuando funciona: **
- Se reduce la incertidumbre (claridad de por qué/para qué).
- Se aumenta la sensación de control (autonomía).
- Se protege la identidad profesional (respeto por el criterio técnico).
- Se ve progreso real (wins + visibilidad).
- Se elimina el miedo (seguridad psicológica).
Si quieres, dime qué tipo de cambio era (reorg, new stack, cloud, DevSecOps, Agile, recorte, etc.) y te digo qué combinación suele rendir más y qué antipatrón suele sabotearlo (porque casi siempre hay uno).
Automatic translation · View original