💻 computer science

What Characterizes a Software Leader? Identifying Leadership Practices from Practitioners Social Media

Mediante el análisis de 116 artículos escritos por profesionales de la comunidad Dev.to, este estudio identifica y clasifica 103 prácticas de liderazgo recomendadas y desaconsejadas en cinco áreas clave, revelando que el liderazgo eficaz en el desarrollo de software se define principalmente por habilidades gerenciales e interpersonales más que por la experiencia técnica.

Autores originales: Murilo Coelho, Denivan Campos, Mariana Maia Bezerra, Matheus Paixao, Allysson Allex Araujo, Savio Freire

Publicado 2026-05-04

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Murilo Coelho, Denivan Campos, Mariana Maia Bezerra, Matheus Paixao, Allysson Allex Araujo, Savio Freire

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás tratando de averiguar qué hace que un capitán de barco sea excelente. La mayoría de los estudios examinan las descripciones oficiales del puesto, las reglas escritas en el manual o los títulos que las personas ostentan. Pero este artículo decidió hacer algo diferente: salió a la "plaza del pueblo" (un sitio web de redes sociales llamado Dev.to) y escuchó a los propios marineros. Leyeron 116 historias escritas por desarrolladores de software sobre cómo se siente realmente liderar un equipo en el mundo real.

Esto es lo que descubrieron, desglosado en ideas y metáforas simples.

El Panorama General: No Se Trata de las Herramientas, Se Trata de las Personas

Si piensas que un líder de software es simplemente un superprogramador que conoce las matemáticas más complejas, este estudio dice que estás mirando la parte equivocada del barco.

Los investigadores descubrieron que el liderazgo en software se trata principalmente de "habilidades blandas" y de gestionar personas, no de escribir código.

La Metáfora: Imagina un equipo de software como un jardín. Las "habilidades técnicas" son las semillas y la tierra. Pero el "líder" es el jardinero. El jardinero no necesita ser el mejor haciendo crecer las semillas (las plantas hacen eso); necesita saber cómo regarlas, arrancar las malas hierbas, protegerlas de las tormentas y asegurarse de que reciban suficiente sol.
El Hallazgo: Los líderes más elogiados no fueron los que escribieron más código; fueron los que fueron buenos hablando, escuchando, ayudando a otros a crecer y manteniendo al equipo feliz.

Lo Que Hacen los Buenos Líderes (La Lista "Recomendada")

Los investigadores identificaron 103 cosas que hacen los buenos líderes. Si tuvieras que elegir las tres principales, son:

Ser una persona sociable: Cultivar buenas relaciones y habilidades interpersonales.
Delegar: Confiar en el equipo para hacer el trabajo y permitirles brillar.
Crecer como gerente: Aprender constantemente a ser un mejor jefe.

La Parte "Técnica":
¿Importa el conocimiento técnico? Sí, pero es como una herramienta especial en la caja de herramientas.

Los líderes necesitan saber lo suficiente para revisar el trabajo (como revisar código) y asegurarse de que la calidad sea alta.
Sin embargo, el estudio encontró que las habilidades técnicas representan solo aproximadamente el 12% de lo que hace que un líder sea exitoso a los ojos de la comunidad. El otro 88% se trata de gestionar personas, estrategia y comunicación.

Lo Que Hacen los Malos Líderes (La Lista "Desaconsejada")

Los investigadores también examinaron lo que los líderes no deberían hacer. ¿El comportamiento más odiado? La microgestión.

La Metáfora: La microgestión es como un padre que no deja que su hijo se ate sus propios zapatos porque cree que el niño lo hará mal. Es estar hovering sobre cada movimiento individual.
Otros Malos Hábitos: Ser arrogante, tener una "mentalidad fija" (negarse a aprender), comunicarse de manera pasivo-agresiva o crear un entorno tóxico donde la gente tenga miedo de hablar.

Curiosamente, los errores técnicos rara vez fueron atribuidos al liderazgo.

Si un trozo de código fallaba, la comunidad generalmente no decía: "El líder falló porque no conocía suficiente código".
En cambio, decían: "El líder falló porque no escuchó al equipo" o "El líder fue demasiado autoritario".
La Metáfora: Si un coche se avería, culpamos al mecánico por el motor roto. Pero si el mecánico es un jefe terrible que le grita a la tripulación y les roba las herramientas, culpamos al jefe, no a sus habilidades con la llave inglesa.

Las Cinco "Habitaciones" del Liderazgo

Los investigadores organizaron todos estos comportamientos en cinco categorías principales, como cinco habitaciones diferentes en una casa:

Gestión y Desarrollo de Personas: La sala de estar. Aquí es donde se hace crecer al equipo, se los orienta y se les hace sentir seguros. (Esta fue la habitación más grande).
Procesos y Ejecución: La cocina. Aquí es donde ocurre el trabajo diario y donde los líderes se aseguran de que las cosas funcionen sin problemas y la calidad sea alta. Esta es la única habitación donde se utilizan intensamente las habilidades técnicas.
Comunicación y Articulación: La puerta principal. Cómo el líder habla con el equipo, los jefes y los clientes.
Visión Estratégica: La habitación del mapa. Mirar el horizonte y decidir hacia dónde va el barco.
Crecimiento Profesional y Personal: El gimnasio. El líder trabajando en su propia mejora personal.

El "Mapa Conceptual"

El artículo termina con un mapa visual (Figura 4). Imagina esto como una hoja de ruta para convertirse en líder.

Muestra que el camino para ser un gran líder de software está pavimentado principalmente con habilidades interpersonales (círculos verdes).
Las habilidades técnicas (círculos naranjas) están ahí, pero son pequeñas piedras de paso, no toda la carretera.
El mapa también destaca los "baches" (comportamientos malos) como la microgestión o la arrogancia que pueden hacer que tu viaje choque.

La Conclusión

Este estudio nos dice que para ser un gran líder en software, no necesitas ser el programador más inteligente de la habitación. Necesitas ser el mejor jardinero de la habitación. Necesitas saber cómo ayudar a tu equipo a crecer, cómo despejar el camino para ellos y cómo mantener el entorno saludable. Si te enfocas en las personas y el proceso, el éxito técnico seguirá.

1. Planteamiento del Problema

Aunque el liderazgo se reconoce como crítico para el éxito de los proyectos de software, la investigación existente se centra predominantemente en roles formales (por ejemplo, Scrum Master, Gerente de Proyecto) y marcos predefinidos (por ejemplo, Agile, Scrum). Esto genera una brecha significativa en la comprensión de:

Cómo el liderazgo es realmente experimentado y demostrado por los profesionales en el trabajo diario.
Los comportamientos informales basados en la práctica que constituyen un liderazgo efectivo (o inefectivo) fuera de las jerarquías organizacionales rígidas.
La desconexión entre los constructos teóricos de liderazgo y la realidad de la práctica de la ingeniería de software.

Los autores argumentan que confiar únicamente en las definiciones de roles formales pasa por alto el aspecto de la "influencia social" del liderazgo y no logra capturar los matices de los comportamientos impulsados por los profesionales que impulsan el rendimiento del equipo.

2. Metodología

El estudio emplea un enfoque de análisis cualitativo de contenido fundamentado en el paradigma Objetivo–Pregunta–Métrica (GQM), utilizando datos de redes sociales para minimizar el sesgo del investigador y capturar perspectivas de profesionales no solicitadas.

Fuente de Datos: La comunidad Dev.to, una plataforma global de acceso abierto para desarrolladores de software.
Recopilación de Datos:
- Recuperación Inicial: Utilizando la API de Dev.to, los autores recuperaron 1.815 artículos etiquetados con #leadership y 21 palabras clave relacionadas (por ejemplo, #techlead, #teamlead, #engineeringleadership).
- Proceso de Filtrado: Se aplicó una rigurosa selección en dos fases:
  1. Exclusión Automatizada: Se eliminaron duplicados, artículos en idiomas distintos al inglés y aquellos con cero interacción (reacciones/comentarios).
  2. Filtrado Manual: Dos investigadores analizaron independientemente 491 artículos contra criterios que aseguraban profundidad, relevancia para la ingeniería de software y verificabilidad del autor (biografía/enlaces profesionales).
- Conjunto de Datos Final: Se seleccionaron 116 artículos curados (publicados entre 2017 y 2024) para su análisis.
Procedimiento de Análisis:
- Unidad de Análisis: Artículos individuales; Unidad de Observación: Segmentos de texto que describen comportamientos específicos.
- Estrategia de Codificación:
  1. Codificación Abierta: Los investigadores extrajeron 893 segmentos de texto (893 menciones) sin códigos preestablecidos, preservando la terminología de los profesionales.
  2. Unificación de Códigos: Se fusionaron códigos similares (por ejemplo, "liderar con el ejemplo" + "liderar mediante la acción" $\rightarrow$ "mostrar el camino a través del ejemplo").
  3. Categorización: Las prácticas se agruparon en cinco categorías basadas en el objeto de la acción (individuo, equipo, tarea, organización) y el enfoque temporal (diario vs. estratégico).
  4. Clasificación: Las prácticas se etiquetaron como Recomendadas o Desaconsejadas y se clasificaron adicionalmente como Gerenciales o Técnicas.
- Análisis Estadístico: Se aplicaron pruebas de correlación Tau de Kendall para identificar patrones de co-ocurrencia entre las principales prácticas.
- Fiabilidad: Lograda mediante confiabilidad inter-evaluadores (Kappa de Cohen = 0.879), triangulación de investigadores y un paquete de replicación abierto.

3. Contribuciones Clave

Caracterización Empíricamente Fundamentada: Una taxonomía de prácticas de liderazgo derivada directamente del discurso de los profesionales, que va más allá de las definiciones de roles formales para capturar comportamientos emergentes.
Mapa Conceptual: Una síntesis visual de 103 prácticas distintas (71 recomendadas, 32 desaconsejadas) organizadas en cinco categorías, distinguiendo entre dimensiones gerenciales y técnicas.
Marco Accionable: Un recurso para que los investigadores teoricen sobre comportamientos de liderazgo y para que profesionales/organizaciones guíen iniciativas de contratación, mentoría y capacitación basadas en el consenso real de la comunidad.
Repositorio Abierto: Todos los conjuntos de datos, esquemas de codificación y scripts están disponibles públicamente para garantizar transparencia y replicabilidad.

4. Resultados Clave

A. Prácticas Recomendadas (71 Prácticas Distintas)

Dominio de las Habilidades Blandas: Las prácticas recomendadas más frecuentes son Gerenciales e Interpersonales, no técnicas.
- Top 3: Cultivar Habilidades Interpersonales (47.4% de los artículos), Gestionar y Delegar el Trabajo del Equipo (39.6%) y Practicar Habilidades Gerenciales (35.3%).
Rol Técnico: Las prácticas técnicas representan solo el 12.6% de las menciones recomendadas. Cuando están presentes, se centran en la supervisión y habilitación (por ejemplo, Revisiones de Código, Garantía de Calidad, Documentación Técnica) en lugar de la codificación práctica.
Categorías:
- Gestión y Desarrollo de Personas: Mayor volumen de menciones (31.0%).
- Procesos y Ejecución: La única categoría con un peso significativo de práctica técnica (8.0% del total de menciones).
Correlación: Las 10 prácticas recomendadas principales muestran correlaciones positivas estadísticamente significativas, lo que sugiere que forman un "clúster" cohesivo de consejos en lugar de consejos aislados.

B. Prácticas Desaconsejadas (32 Prácticas Distintas)

Fallas Interpersonales: Los comportamientos desaconsejados son abrumadoramente gerenciales y culturales.
- Top 3: Microgestión (7.7%), Patrones de Trabajo Contraproducentes (6.8%) y Estilos de Comunicación Contraproducentes (6.0%).
Ausencia Técnica: Las fallas técnicas representan menos del 2% de las menciones desaconsejadas.
- Cuando se citan problemas técnicos como fallas de liderazgo, se relacionan con procesos de toma de decisiones (por ejemplo, Decisiones Arquitectónicas Unilaterales) o cuellos de botella (por ejemplo, Cuellos de Botella de Datos entre Equipos), no con la corrección técnica del código en sí.
Correlación: La mala comunicación, la falta de equidad y el control excesivo a menudo co-ocurren, formando patrones de comportamiento negativo interconectados.

C. Hallazgos del Mapa Conceptual

Asimetría: Las prácticas recomendadas son mucho más diversas (71 ítems) que las desaconsejadas (32 ítems), lo que indica que los profesionales elaboran más sobre modelos de rol positivos que sobre anti-patrones.
La Hipótesis del "Bonus Técnico": La competencia técnica se considera un requisito previo para la credibilidad, pero no el motor principal del éxito del liderazgo. Por el contrario, el fracaso técnico rara vez se atribuye al "liderazgo", sino más bien a la ejecución de la ingeniería.
Identidad Central del Liderazgo: El liderazgo de software se caracteriza principalmente por la Gestión de Personas, la Visión Estratégica y la Comunicación, con un compromiso técnico limitado a la garantía de calidad y la orientación de procesos.

5. Significado e Implicaciones

Para las Organizaciones: Cuestiona el modelo tradicional de promover al "mejor programador" a un rol de liderazgo. Sugiere que los criterios de promoción deben ponderar fuertemente las habilidades interpersonales, la empatía y la alineación estratégica por encima de la producción técnica pura.
Para la Educación: Los currículos de ingeniería de software deben integrar explícitamente la formación en liderazgo centrada en la resolución de conflictos, la delegación y la seguridad psicológica, en lugar de tratar estos temas como habilidades blandas aprendidas únicamente en el trabajo.
Para los Profesionales: Proporciona una hoja de ruta para los desarrolladores que transicionan al liderazgo, aclarando que su nuevo alcance implica orquestar la salud y la estrategia del equipo en lugar de simplemente escribir código.
Para la Investigación: Valida el discurso en redes sociales como una fuente de datos robusta para estudios empíricos de ingeniería de software, ofreciendo una ventana a la construcción de sentido "no solicitada" de los profesionales que las encuestas y entrevistas pueden pasar por alto.

En conclusión, el estudio redefine el liderazgo de software no como una jerarquía técnica, sino como un proceso social y gerencial donde la capacidad de cultivar un entorno de equipo saludable, autónomo y colaborativo es el determinante principal del éxito.