Liderazgo técnico y proyectos
Sección • Database Strategy

Liderazgo técnico y proyectos

Liderazgo técnico y project management IT: decisiones, equipos, método y consultoría, con historias reales y números de 30 años de proyectos.

14 artículos publicados en esta sección

Esta sección cuenta la parte del oficio que no está en los planes de ejecución: las decisiones, los equipos, el método. Es el espacio del liderazgo técnico, donde personas, sistemas y decisiones deben funcionar juntos.


He visto a project managers hacer llorar a desarrolladores senior en una reunión. He visto equipos brillantes destruidos por PMs que confundían la autoridad con el autoritarismo. He visto software entregado “a tiempo” que no funcionaba, y proyectos de millones de euros acabados en nada.

Y he visto lo contrario: equipos pequeños, autónomos, respetados — que construían sistemas sólidos en una fracción del tiempo y del presupuesto.

La diferencia nunca fue la tecnología. Siempre fue el método.


Después de treinta años en este oficio, hay algo que tengo claro: las personas no dan lo mejor de sí cuando tienen miedo. Lo dan cuando tienen confianza.

Confianza en el equipo. Confianza en el proceso. Confianza en que si se equivocan, no serán castigadas — serán ayudadas.

El project manager que funciona no es el que controla, aterroriza y cuenta horas. Es el que:

  • define objetivos claros y da al equipo la libertad de alcanzarlos
  • construye competencias profundas y las protege de la rotación
  • hace team building cada día, no una vez al año en el karting
  • mide resultados, no horas en la oficina
  • usa el smart working como ventaja competitiva, no como concesión
  • cuando algo sale mal, se pone delante del equipo, no detrás

📊 Cómo trabajo yo #

Mi enfoque es Scrum — pero Scrum hecho en serio, no la liturgia de los post-it.

El Scrum que funciona se basa en un pacto: transparencia radical, responsabilidad compartida y autonomía en el “cómo”. El PM define el qué y el por qué. El equipo decide el cómo. Porque quien escribe el código sabe mejor que nadie cómo escribirlo.

Y este pacto funciona aún mejor con el smart working. El daily standup? 15 minutos en una llamada. La sprint review? Pantalla compartida con el cliente, que ve el software — no las diapositivas. La retrospectiva? Una hora en la que el equipo dice la verdad, porque no tiene al PM a dos metros mirándolo fijamente.

Mido pocas cosas, pero las mido bien:

MétricaQué dice
VelocityCuánto entrega el equipo por sprint
Lead timeCuánto pasa desde la solicitud hasta el lanzamiento
Bug escape rateCuántos defectos se escapan a producción
Sprint goal success% de objetivos de sprint logrados
Team happinessCómo se siente el equipo — la métrica más importante

La última — team happiness — es la que los PMs tradicionales nunca miden. Un equipo feliz no es un equipo que se divierte. Es un equipo que se siente respetado, escuchado y valorado. Y un equipo así produce más. No porque trabaje más horas. Porque trabaja mejor.


📚 De qué hablo aquí #

Historias reales, números concretos y lecciones aprendidas. Nada de teoría de manual. Solo lo que he visto funcionar — y lo que he visto fracasar.

Hablo de inteligencia artificial aplicada al workflow, de consultoría IT y sus costes ocultos, de smart working como ventaja competitiva. Cada artículo nace de una experiencia real — la mía.


No hacen falta revoluciones. Hacen falta decisiones precisas, implementadas con método.

Y la capacidad de decir “no” a quien te vende complejidad cuando la solución es simple.

Últimos artículos

Liderazgo técnico y proyectos
Destacado

La IA muestra el síntoma. El board pregunta por la causa.

Datadog y Dynatrace muestran síntomas, no causas. Cómo explicar al board por qué la observability moderna no basta sin un lector competente.

20 October 2026 10 min
Más artículos de la sección
El reinicio lo resolvió. El problema sigue ahí.
Liderazgo técnico y proyectos

El reinicio lo resolvió. El problema sigue ahí.

Un incident que se cierra sin causa reconstruida no es un episodio aislado. Cómo leer AWR, ASH y change log en frío antes de que llegue el segundo fallo.

Más recursos, misma causa
Liderazgo técnico y proyectos

Más recursos, misma causa

Por qué añadir CPU, RAM o IOPS rara vez resuelve un database mission-critical que va lento — y qué mirar antes de firmar el presupuesto.

El doctor completamente loco: un Commodore 64, una puerta cerrada y el oficio de comprender
Liderazgo técnico y proyectos

El doctor completamente loco: un Commodore 64, una puerta cerrada y el oficio de comprender

Un Commodore 64, un programa modificado para insultar al padre y una puerta cerrada con llave: cómo empieza una carrera de 30 años en ingeniería de bases de datos.

De rivales a co-autores: cómo Booch, Rumbaugh y Jacobson inventaron UML (y lo que queda hoy)
Liderazgo técnico y proyectos

De rivales a co-autores: cómo Booch, Rumbaugh y Jacobson inventaron UML (y lo que queda hoy)

La historia de los Three Amigos de UML y RUP: cómo Booch, Rumbaugh y Jacobson, de rivales, unificaron el object-oriented modeling. Y lo que queda hoy.

5 reglas que he visto funcionar en los equipos de proyecto que aguantan
Liderazgo técnico y proyectos

5 reglas que he visto funcionar en los equipos de proyecto que aguantan

Gestión de proyectos: 5 reglas observadas en equipos que aguantan bajo presión. Psychological safety, bus factor, outcome vs output, knowledge transfer.

AI Manager y Project Management: cuando la inteligencia artificial entra en los proyectos
Liderazgo técnico y proyectos

AI Manager y Project Management: cuando la inteligencia artificial entra en los proyectos

AI Manager: el rol que gobierna el impacto de la inteligencia artificial sobre arquitecturas, procesos y personas. Reflexiones desde 30 años en IT.

Pagos a 60-90-120 días: la normalidad italiana que no existe en Europa
Liderazgo técnico y proyectos

Pagos a 60-90-120 días: la normalidad italiana que no existe en Europa

Pagos a 60-90-120 días en consultoría IT italiana: comparación con las reglas europeas. DSO, directiva 2011/7/UE y estrategias para freelancers IT.

Bici vs Coche en Roma: la mañana que me abrió los ojos
Liderazgo técnico y proyectos

Bici vs Coche en Roma: la mañana que me abrió los ojos

Pendolarismo en Roma: Brompton eléctrica vs coche. 18 minutos vs 50, 35€ de aparcamiento ahorrados. La elección de movilidad sostenible, datos reales.

Smart working en consultoría IT: los números que nadie quiere mirar
Liderazgo técnico y proyectos

Smart working en consultoría IT: los números que nadie quiere mirar

Smart working en consultoría IT: análisis económico y estratégico del trabajo remoto. Números reales, KPIs, presenteísmo y productividad vs oficina.

Cuando el caos se convierte en método: AI y GitHub para gestionar un proyecto que nadie quería tocar
Liderazgo técnico y proyectos

Cuando el caos se convierte en método: AI y GitHub para gestionar un proyecto que nadie quería tocar

Gestión de proyectos con AI y GitHub: transformar un proyecto caótico en workflow medible con issue tracking, code review e inteligencia artificial.

Liderazgo técnico y proyectos

Standup meeting: por qué solo funcionan si duran 15 minutos

Standup meeting Scrum: por qué solo los 15 minutos los hacen funcionar. Timeboxing, parking lot y reglas prácticas del daily meeting que aguantan.

La técnica del Sí-Y: cómo evité una discusión que estaba a punto de estallar
Liderazgo técnico y proyectos

La técnica del Sí-Y: cómo evité una discusión que estaba a punto de estallar

La técnica Yes-And del teatro de improvisación aplicada a la gestión de conflictos en equipos IT. Caso real de una reunión que iba a estallar.

4 millones de euros, dos multinacionales, cero software: historia real de un fracaso anunciado
Liderazgo técnico y proyectos

4 millones de euros, dos multinacionales, cero software: historia real de un fracaso anunciado

Caso real de gestión de proyectos: cliente asegurador gasta 4 millones en consultoría IT y obtiene cero software funcionando. Lecciones vendor lock-in.

Explora otras secciones