- Los equipos grandes centrados en especialistas sufren una caída drástica en la productividad y la eficiencia de colaboración debido a dependencias internas, errores de comunicación, cuellos de botella y responsabilidad dispersa
- En las reuniones diarias de standup, gran parte de lo que se dice se vuelve innecesario o aburrido, y el aumento del tamaño del equipo y la especialización termina provocando desconexión en la comunicación y desinterés
- Se probaron varios enfoques, como la separación por tecnología (frontend/backend), equipos temporales por feature y uso de consultores externos, pero al final lo que dio el efecto más práctico fue cambiar a roles generalistas
- La colaboración grupal, como el mob programming, impulsa el intercambio de conocimiento, la autonomía, la responsabilidad y la motivación, y resulta más favorable para la colaboración orientada a resultados y el crecimiento que insistir en un solo campo
- Aun así, también existen efectos secundarios de la generalización (menor especialización, riesgo de burnout), por lo que son indispensables la experimentación continua y las mejoras culturales
Problemas cuando el equipo es demasiado grande
- Problemas que comenzaron en un equipo grande de 14 personas: en el standup, la mayor parte de la conversación era innecesaria, y eran frecuentes las omisiones al transmitir trabajo y la aparición de tareas no oficiales
- Incluso al cambiar a standups asíncronos (Slack, etc.), se perdieron conversaciones clave y oportunidades de colaboración, y todo terminó degradándose en simples reportes
Distintos experimentos de división y operación
- Separación por tecnología (Task Force): se dividió entre frontend y backend, pero de inmediato aparecieron problemas de dependencia mutua y más tiempo invertido por tener que participar en standups adicionales
- Equipos temporales por feature: reasignación temporal de personas según la implementación de funciones específicas, lo que generó problemas de mantenimiento y gestión de recursos
- Incorporación de consultores externos: incluso con un equipo ya grande, seguía siendo ineficiente, además de la presión de la alta dirección por aprovechar esos recursos
La solución que finalmente funcionó
- Se adoptó un modelo de generalistas en lugar de especialistas
- Sin separar roles como frontend, backend, QA o DevOps, se compartió el conjunto completo de habilidades alrededor de un mismo objetivo/producto
- Se lograron mejor intercambio de conocimiento, menos dispersión de responsabilidad, eliminación de cuellos de botella y entregas más rápidas y de mayor calidad
- La colaboración grupal, como el mob programming, reforzó la comunicación, la autonomía y el sentido de ownership
Por qué los generalistas fueron efectivos
- Contexto y propósito compartidos: incluso en áreas nuevas, la curva de aprendizaje se suaviza al aprender con base en el mismo producto/objetivo
- Necesidades acotadas: basta con aprender ciertas herramientas específicas (como CI/CD); se priorizan la productividad y la mantenibilidad por encima de una especialización profunda
- Se cumplen los 3 elementos de la motivación (autonomía, dominio y propósito), apoyando el sentido de pertenencia y el crecimiento del equipo
- Cultura igualitaria: acceso equitativo, adquisición autónoma de conocimiento, distribución de autoridad y responsabilidad, y aprendizaje colectivo
- Los 3 elementos de la responsabilidad (conocimiento, autoridad y responsabilidad) quedan claros, lo que permite resultados rápidos y de alta calidad basados en ownership
Efectos secundarios y límites
- Salida de especialistas: la generalización no le funciona a todo el mundo, y en algunas personas puede provocar burnout o sobrecarga de recursos
- Falta de profundidad en la especialización: al tocar varios stacks de forma superficial, puede verse afectado el dominio profundo de un área
Conclusión y aprendizajes
- No existe una solución única, y es más importante una cultura de experimentación y mejora
- Las desventajas del modelo de especialistas (cuellos de botella, desconexión en la comunicación, trabajo ficticio, pérdida de contexto) pueden aliviarse con generalistas y colaboración grupal
- En última instancia, el modelo óptimo puede variar según los objetivos, las personas, el presupuesto y las características del producto
- La clave es una cultura de experimentación abierta, feedback y mejora continua
4 comentarios
Soy generalista, pero esto es lo que he sentido en la práctica.
Lo útil es ser generalista, pero a quienes de verdad se les reconoce el "valor" es a los especialistas.
Incluso si salen de la misma universidad y con las mismas calificaciones, al final la realidad es que los especialistas reciben una remuneración 2 a 3 veces más alta.
Yo también pienso algo parecido.
Pero, en mi opinión, tomando como referencia el software, salvo que sea deep tech de EE. UU., no parece que los especialistas sean realmente tan especiales.
¿Podría pedirte un ejemplo, quizá? Tengo curiosidad por saber qué tan “especial” es en la práctica eso de que te llamen especialista...
Según RR. HH., parece que en las grandes empresas o empresas medianas piden alrededor de 3 años de experiencia, y mi criterio para un "especialista" es, desde la perspectiva de backend, si puede aprovechar LLM para diseñar una arquitectura que cualquiera pueda usar fácilmente y que además considere alta disponibilidad.
Por ejemplo, yo soy generalista, pero puedo diseñar de forma tan simple que hasta un niño de primaria la entienda una arquitectura capaz de manejar más de 100 millones de usuarios de tráfico para cualquier servicio en Corea.
Pero como también soy generalista, me rechazan en la revisión de CV de las grandes empresas jajaja