La trampa del «rockstar developer»
La exclusión competitiva y el efecto Pigmalión
Supongamos que inicias un proyecto y contratas a dos desarrolladoras con las mismas habilidades y experiencia. Tienes poco capital así que hablamos de muy poca experiencia.
Durante el primer par de años una de las desarrolladoras resulta ser de esas que vive por y para desarrollar software. Se lleva trabajo a casa, se sigue formando en su tiempo libre y siempre está disponible para apagar fuegos. Tras unos años es muy notable su progresión. Una especie de Brent Geller en The Phoenix Project, dueña de todo el conocimiento del sistema y persona indispensable para cualquier iniciativa. Me referiré a ella como 10x de ahora en adelante.
La otra persona se limita a hacer sus tareas tal como están descritas, durante su horario laboral. En su tiempo libre normalmente desconecta de su profesión. Durante años apenas progresa en sus habilidades ni en el ámbito de su rol, se limita a desarrollar lo que le entra en su backlog. Me referiré a ella como 1x de ahora en adelante.
La manager cada vez confía menos en 1x y sus skills y es 10x quien normalmente asume las tareas de mayor responsabilidad lo que también le genera más oportunidades de actos de heroicidad y de hacer más méritos.
La diferencia de progresión entre 1x y 10x es tan grande que la manager se plantea despedir a 1x e intentar encontrar otra 10x.
Ahora os planteo algunas preguntas:
¿Es 1x peor profesional que 10x?
¿Tiene toda la culpa de no haber progresado durante años?
¿Puede que 1x no esté hecha para esta profesión?
¿Es realmente una persona apática que no le importa ni su profesión ni el proyecto?
¿Se está aprovechando de la falta de asertividad de su manager y demás compañeras y está llevándose el salario esforzándose menos que las demás?
Las respuestas a todas estas preguntas podrían ser un sí, pero cabe también el tal vez, el depende y por supuesto, el no.
La Navaja de Hanlon y la Complejidad Humana
Como ya comenté en la tragedia del código compartido, rara vez actuamos con mala intención así que en estos casos suelo aplicar la navaja de Hanlon como modelo mental:
Nunca atribuyas a la maldad lo que se explica adecuadamente por la estupidez.
Es trivial estar de acuerdo en que el ser humano constituye un sistema de complejidad abrumadora. Compuestos por innumerables átomos, emergen de nosotros comportamientos que desafían la previsibilidad. A pesar de nuestra complejidad innata, resulta reduccionista atribuir nuestras acciones o fallos meramente a la genética o a nuestras experiencias previas.
Considerar a alguien como 1x sin tomar en cuenta el entorno en el que se desenvuelve omite el hecho esencial de que, a diferencia de objetos inanimados como una piedra o una mesa, las personas no operamos en vacío; somos sistemas abiertos en constante interacción con nuestro entorno.
Edgar Morin define los sistema cerrados y abiertos en su Introducción al Pensamiento Complejo:
Los sistemas cerrados están en estado de equilibrio, es decir que los intercambios de materia y energía con el exterior son nulos. Por el contrario en un sistema abierto como lo es un ser viviente, hay desequilibrio en el flujo energético que los alimenta y, sin ese flujo, habría un desorden organizacional que conllevaría una decadencia rápida. Las leyes de organización de lo viviente no son de equilibrio; sino de desequilibrio, retomado o compensado, de dinamismo estabilizado.
La inteligibilidad del sistema debe encontrarse no solamente en el sistema mismo, sino también en su relación con el ambiente, y esa relación no es una simple dependencia, sino que es constitutiva del sistema.
Por tanto no podemos pensar en 1x y los efectos que genera en su entorno sin tener en cuenta que el entorno también genera efectos en su comportamiento.
Entendiendo el Sistema
Cuando os introduje al contexto del equipo, lo que compartí fue apenas la punta del iceberg, destacando solo los síntomas superficiales de problemas más profundos. Sin embargo, subyacente a estos síntomas, existe una cultura organizacional compleja; un sistema integral por explorar. Para ilustrar cómo operaba este equipo, tomaré prestado algunos rasgos característicos de lo que John Cutler denomina una factoría de funcionalidades (feature factory):
El éxito se mide en torno al «lanzamiento» con poca discusión sobre el impacto.
El roadmap es una lista de características, no áreas de enfoque y/o resultados.
Las historias de usuario son prototipos de alta fidelidad y las desarrolladora se limitan a implementarlas.
Una vez que el trabajo está «terminado», el equipo pasa inmediatamente al siguiente «proyecto».
Se cambian las prioridades constantemente para implementar funcionalidades para cerrar nuevos acuerdos.
Se celebra la épica, las heroicidades por sacar funcionalidades rápido y arreglar bugs a deshoras.
Multitarea crónica y sobreutilización dejando cero margen para la formación, el cuidado de la calidad y el pensamiento a largo plazo.
En este sistema 10x parte con una ventaja. Ella está dispuesta a aprender lo que necesita para hacer su trabajo en su tiempo libre, así que en poco tiempo aventaja a 1x en habilidades. Esta ventaja de partida hace que su manager empiece a confiarle cada vez más responsabilidades y retos épicos. Además, a 10x no le importa llevarse trabajo a casa o que le llamen fuera de su horario así que está dispuesta a asumir riesgos. La manager valora mucho este comportamiento así que cada vez que 10x apaga un fuego fuera de horario laboral, o arregla un bug en el último momento antes de cerrar un trato, está haciendo méritos. 10x tiene grandes incentivos para seguir formándose y para seguir asumiendo riesgos. La manager también tiene más incentivos para confiar en 10x.
Por su parte 1x tiene una evolución plana pues no está dispuesta a llevarse trabajo a casa. El día a día no le deja tiempo para afilar su hacha así que soluciona las tareas más básicas sin llegar a adquirir un conocimiento profundo de su pila de desarrollo. Esto le lleva a cometer más errores que como no está disponible para solucionarlos fuera de horario de trabajo hace que la manager cada vez pierda más la confianza en sus habilidades y en su compromiso con el proyecto.
Trampa de la Exclusión Competitiva
Este escenario, aunque hipotético, ilustra perfectamente lo que se denomina la trampa de la exclusión competitiva.
Utilizar la riqueza, las ventajas, el acceso privilegiado o la información interna para crear más riqueza, más ventajas, para poder disponer de más información o acceder mejor a ella, son ejemplos del arquetipo llamado «el éxito que atrae al éxito». Esta trampa surge cada vez que los ganadores de una competición reciben, como parte de su recompensa, los medios para competir de una manera aún más efectiva en el futuro. Se trata de un bucle de retroalimentación reforzador que divide rápidamente un sistema en ganadores que siguen ganando y perdedores que siguen perdiendo.
— Donella Meadows. Pensar en sistemas
En esta trampa que también se conoce como «el éxito que atrae el éxito», la oportunidad se presenta solo a aquellos que han tenido éxito en el pasado, constituye un bucle de retroalimentación positiva donde el éxito engendra éxito.
Este es un concepto muy conocido en el campo de la ecología, donde se conoce como «principio de exclusión competitiva». Según este principio, dos especies diferentes no pueden vivir en el mismo nicho ecológico y competir por los mismos recursos. Al tratarse de dos especies diferentes, una se reproducirá necesariamente más rápido o será capaz de explotar los recursos de manera más eficiente que la otra. Se apoderará de una parte mayor de los recursos, que le proporcionarán la capacidad de multiplicarse más y seguir ganando.
Existe un concepto similar en biología evolutiva conocido como el «efecto fundador». Describe cómo una nueva población fundada por un número muy pequeño de individuos puede llevar a diferencias significativas en la diversidad genética en comparación con su población original. Esto puede resultar en que características genéticas raras en la población original se vuelvan comunes en la población descendiente. En sociología, se refiere a cómo las características culturales, normativas, o de otro tipo de un pequeño grupo de individuos fundadores pueden tener un impacto duradero en la cultura y estructura de una comunidad o sociedad. Esto puede ser particularmente evidente en comunidades cerradas, equipos, o startups.
El «efecto fundador» al igual que la «la exclusión competitiva» describe como las características iniciales de un pequeño grupo pueden tener un impacto desproporcionado en el futuro desarrollo de un grupo mayor. Estas ventajas iniciales pueden autopotenciarse y llevar a desequilibrios significativos en sistemas competitivos o cooperativos como lo es un equipo de desarrollo de producto.
Efecto Pigmalión
A medida que el bucle de refuerzo de 10x se hace más intenso este se empieza a ganar la etiqueta de rockstar, de buena profesional. Por el contrario, mientras que el círculo vicioso de 1x se hace más intenso le encasilla como mala profesional, apática, desmotivada e incapaz.
Tanto la manager, como 10x y 1x asumen esas etiquetas y comienza a manifestarse el efecto Pigmalión o el efecto Golem (efecto Pigmalión negativo) en el caso de 1x.
El efecto Pigmalión es un fenómeno que se utiliza en psicología y pedagogía para referirse a la potencial influencia que ejerce la creencia de una persona en el rendimiento de otra. Funciona como una profecía autocumplida, una expectativa que incita a las personas a actuar en formas que hacen que la expectativa se cumpla.
Esto significa que, además de las causas originales impulsadas por la exclusión competitiva, surgen nuevos factores que retroalimentan y amplifican aún más la situación existente.
Edgar Morin define en su marco teórico, la causalidad recursiva como un proceso en el cual los efectos y causas se interrelacionan de manera cíclica, es decir, los efectos pueden influir o generar nuevas causas en un ciclo continuo lo cual contrasta con la visión lineal y unidireccional de la causalidad tradicional, donde A causa B en una relación simple y directa.
La causalidad recursiva implica que, en sistemas complejos, los procesos no son meramente lineales; en cambio, se retroalimentan en un bucle donde los resultados de un proceso pueden afectar o modificar las condiciones iniciales de ese mismo proceso. Este concepto es fundamental para entender fenómenos dinámicos y autoorganizados como los que se dan en una organización.
La Sociedad misma, como un todo organizado y organizador, retroactúa para producir a los individuos mediante la educación, el lenguaje, la escuela. Así es que los individuos, en sus interacciones, producen a la Sociedad, la cual produce a los individuos que la producen. Eso sucede en un circuito espiralado a través de la evolución histórica.
No está el individuo por una parte, la Sociedad por otra, la especie de un lado, los individuos del otro, de un lado la empresa con su organigrama, su programa de producción, sus estudios de mercado, del otro lado sus problemas de relaciones humanas
— Edgar Morin
¿Cómo salir de esta trampa?
Escapar de este entramado de bucles retroalimentados no es tarea fácil. De hecho, si has estado inmerso en este sistema por años, puede ser especialmente desafiante reconocer que el verdadero problema reside en el sistema mismo, no en los individuos que lo componen, y menos aún aceptar que uno, como líder, pueda ser parte del dilema. No obstante, esta percepción puede cambiar cuando un observador externo analiza la situación, dado que no ha experimentado la gradual adaptación a las dinámicas de este sistema.
El núcleo del problema radica en una cultura que tolera poco el error, donde únicamente se celebra el éxito y la presión por lanzar nuevas funcionalidades reduce el espacio para la colaboración, el aprendizaje continuo y el pensamiento estratégico a largo plazo.
Os propongo algunas estrategias para contrarrestar esta dinámica:
Cultivar una cultura de experimentación: Valorar tanto el aprendizaje derivado de los fracasos como los éxitos.
Priorizar la entrega de valor: Enfocarse en el valor entregado al usuario más que en la cantidad de funcionalidades lanzadas.
Releases aburridas y rutinarias: Buscar que las actualizaciones sean rutinarias y predecibles, en lugar de carreras contra el tiempo que demanden esfuerzos sobrehumanos y hotfixes fuera de horario.
Cuidar la calidad del código: Tener un código sostenible es requisito indespensable para que llevar código a producción sea un proceso rutinario.
Involucrar asesoría especializada: Dada la complejidad de reconocer y abordar estos problemas desde dentro, la orientación de una coach experimentada en cambios culturales puede ser invaluable para mitigar riesgos de destruir el equipo.
Promover el aprendizaje continuo: Fomentar la difusión del conocimiento a través de prácticas como programación en pareja, comunidades de práctica, mentorías y programas para aprendices, asegurando que nadie se quede atrás. Un equipo es tan fuerte como su miembro más vulnerable.
Abrazar el patrón de «never the expert» para evitar la concentración del conocimiento en unas pocas manos, lo cual es fundamental para prevenir la formación de silos de información.
El patrón never the expert viene a dar nombre a una buena práctica para repartir el conocimiento: que las cosas no las haga el que más sabe. Puede parecer contra-intuitivo, pero es la base para evitar auténticos pozos de conocimiento.
— Luis Artola. Software Economics
Para concluir, mi perspectiva no se opone al concepto del «10x engineer» o al «rockstar developer» como tales. Valoro profundamente la excelencia y estoy convencido de que, dentro de un entorno y una cultura adecuados, la extraordinaria capacidad individual no solo es deseable sino que también puede servir como un catalizador para elevar a todo el equipo. Sin embargo, es crucial desarrollar ambientes laborales que enfaticen la colaboración, el crecimiento conjunto y un equilibrio saludable entre la vida laboral y personal. La clave para lograr un éxito sostenido y fomentar la innovación reside menos en destacar individualidades y más en la fortaleza colectiva, diversidad y bienestar del equipo. En este sentido, uno de nuestros valores fundamentales en Audiense es la «🏋️♀️ Excelencia: Dar lo mejor de nosotros mismos» que equilibramos con la «🤜🤛 Colaboración: Trabajamos mejor en equipo».
Serie: las trampas de los sistemas complejos
Esta entrega forma parte de una serie sobre las trampas de los sistemas complejos aplicadas al desarrollo de productos:
Elusión de las reglas y persecución del objetivo equivocado: La trampa del testing coverage.
Desplazamiento de la carga hacia la intervención: La trampa de la adicción al parche.
Deriva hacia el bajo rendimiento: La Trampa de la Erosión de Metas y el Síndrome de la Rana Hervida.
Tragedia de los recursos comunes: La tragedia del código compartido.
Si te interesa el tema del pensamiento sistémico aplicado al desarrollo de software y aprender a utilizar estas herramientas, al momento de escribir este post estoy preparando un taller sobre cómo usar y sacarle partido a estas herramientas.
Recientemente me topé con tu publicación en LinkedIn y he tenido la oportunidad de explorar tu blog. Me ha impresionado la calidad y relevancia del contenido que compartes.
Sin duda, me he suscrito para no perderme tus futuras publicaciones. Con gran interés, espero leer tu próximo artículo.