Many of the recommended readings on management focus on the rational factors of a project, such as designing workflows or designing tasks.
In most of these cases, the approach most used in project management (and therefore in team management) centers on processes, where each task is defined as a set of rules.
So what could be behind this failure? I invite you to keep reading ⬇️
The data from Harvard Business Review tells us that 73% of IT projects fail or are delayed. The reason? We have become obsessed with code and processes, forgetting that the people typing are people with emotions.
We often obsess over the rational side of projects: designing perfect workflows, defining tasks down to the millimeter, and setting rules for everything. However, the data is stubborn. Harvard Business Review already warned us that, under that rigid scheme, the success rate for IT projects stays at a poor 27%. Even worse: one in six projects ends up costing three times what was planned and is delivered with a huge delay.
Why do we fail so much?
Because we keep insisting on using tools and theories that idolize logic and forget what truly moves the needle: people and their emotions. That is where the game is played.
We do not reject methodology. Having clear deadlines and delivering on time is vital. But our experience tells us that this is only the foundation. The real difference, our secret ingredient if you want to call it that, lies in leadership and in how we manage people.
If we get scientific, it all starts in the cerebral amygdala (to visualize it better, imagine a line entering through your eyes and another entering through your ears. Where both lines cross, inside the brain, is where they reside and are two). This small part of the brain is what ignites emotions and controls impulses. It is the seat of primary leadership and emotional intelligence.
We know that a motivated team works better; the leader's task is to create that spark. But here the big question arises: if the leader must motivate everyone... who motivates the leader?
We cannot leave the motivation of the whole team in the hands of a few exhausted people. Just as we distribute tasks, we must distribute leadership. We need shared leadership. And for that, we have to take care of those who steer the ship.
For a leader to work, they need to cultivate five major areas:
- Knowing yourself: Knowing what you are good at and where you struggle. From Talent Management, our job is to give them that mirror.
- Self-control: Knowing how to balance demands with rewards. Not everything goes, and keeping that balance well calibrated is essential.
- Having your own drive: The leader must be the first to be convinced. Their leadership must come from within, not be an external imposition.
- Walking in the other's shoes: Empathy is not only understanding how a colleague feels, it is also detecting when they are ready to grow.
- Handling people well: Managing friction, driving change, and uniting forces among colleagues. Ultimately, being the one who inspires and guides.
But mind you, having these qualities built in is not enough. Day to day wears anyone down. That is why any people strategy must include plans to recharge the batteries of these profiles.
How do we do it in practice?
First, by looking for natural leaders. Never force anyone to carry that responsibility if it does not come naturally to them.
Second, by giving them tools to see themselves clearly. At Mobiliza we use our competency matrices and the InProgress system, which lets each person know where they stand and refine the skills that help us grow.
And third, by speaking plainly. Our culture is based on constant feedback. We use forums and tools where the team's referents share their views directly with management.
In the end, processes do help, of course. But emotional intelligence—that capacity to understand and manage what we feel and what others feel—is the piece that separates a mediocre project from a resounding success.
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