Hay una figura que la industria del software venera desde hace décadas: el programador 10x. Esa persona casi mítica que, dicen, produce diez veces más que un desarrollador promedio, que resuelve en una tarde lo que a otros les lleva una semana, que parece tener un cable directo entre el cerebro y el teclado. La buscamos al contratar, la premiamos cuando creemos haberla encontrado, organizamos equipos enteros alrededor de ella. Y yo mismo, en mis primeros años, caí en ese encantamiento: pensaba que un buen equipo era, sobre todo, una colección de personas muy buenas individualmente. Con el tiempo, y con bastantes cicatrices de por medio, fui cambiando de opinión. Vi equipos llenos de talento individual rendir mal, y vi equipos de gente “normal” lograr cosas extraordinarias. Y entendí algo que ahora me parece obvio pero que me costó años aceptar: el rendimiento de un equipo no es la suma de los rendimientos individuales. Hace poco, leyendo un libro sobre liderazgo que no tiene nada que ver con programación, me encontré con esa misma idea formulada con una claridad que me dieron ganas de discutirla acá.
El encanto y la trampa del 10x#
Empecemos por ser justos con la idea, porque tiene su parte de verdad. Sí existen personas extraordinariamente productivas. Hay desarrolladores que, por talento, experiencia o forma de pensar, resuelven problemas con una velocidad y una elegancia que asombran. Negar eso sería ridículo. El problema no es reconocer que esa gente existe; el problema es lo que construimos alrededor de esa creencia, y las conclusiones equivocadas que sacamos de ella.
La primera trampa es de medición. Cuando decimos que alguien “produce diez veces más”, ¿qué estamos midiendo exactamente? Casi siempre, sin darnos cuenta, medimos lo más fácil de contar: líneas de código, features cerradas, tickets resueltos, velocidad visible. Pero esas métricas capturan una parte chiquita de lo que hace valioso a alguien en un equipo, y dejan afuera lo más importante. No miden si ese código se puede mantener, si otros lo entienden, si esa persona dejó al equipo mejor o peor que como lo encontró. Un desarrollador puede cerrar el doble de tickets que sus compañeros y, al mismo tiempo, generar el triple de trabajo futuro para todos los demás. Eso no es ser 10x; es trasladar el costo hacia adelante y hacia los costados, donde nadie lo está contando.
La segunda trampa es más sutil y más cara: organizar un equipo alrededor de sus estrellas suele debilitarlo. Cuando todo gira en torno a una o dos personas brillantes, el equipo se vuelve frágil. El conocimiento se concentra, las decisiones dependen de pocos, y el día que esa persona se va de vacaciones, se enferma o renuncia, descubrimos cuánto dependíamos de ella. Lo escribí hace unos meses hablando de las dependencias invisibles, y vale igual para las personas: una dependencia crítica que vive en la cabeza de un solo individuo es un riesgo, no una fortaleza, por más brillante que sea ese individuo.
De dónde salió ese número, y por qué importa#
Vale la pena detenerse un segundo en el propio número, porque dice algo sobre cómo construimos nuestras certezas. La idea del 10x viene de un estudio de fines de los años sesenta que encontró grandes diferencias de productividad entre programadores. Lo curioso es que ese estudio ni siquiera había sido diseñado para medir eso: buscaba comparar dos formas de programar de la época, y la variabilidad entre personas apareció casi como un hallazgo lateral. Sobre esa base, y sobre un puñado de mediciones igual de viejas, se edificó toda una mitología: el ingeniero diez veces mejor, casi una categoría de ser humano aparte. El problema es que esas mediciones se hicieron sobre tareas individuales y aisladas, con lenguajes y condiciones que no se parecen en nada a cómo se construye software hoy, en equipo, sobre sistemas que viven años. Tomar una medición de laboratorio sobre tareas chicas y convertirla en una teoría sobre el valor de las personas en una organización es un salto enorme, y lo dimos casi sin pensarlo.
No traigo esto para negar que haya diferencias de talento —las hay, evidentes— sino para señalar lo fácil que es que un dato descontextualizado se vuelva dogma. El 10x dejó de ser una observación acotada sobre rendimiento individual y pasó a ser una forma de mirar el mundo: contratamos buscando a esa persona, diseñamos procesos de selección para detectarla, estructuramos incentivos para premiarla. Construimos prácticas enteras sobre una métrica que mide lo más fácil de medir y que ignora casi todo lo que de verdad pasa en un equipo. Es, en el fondo, el mismo error que critiqué cuando hablé de elegir modelos de IA por su potencia: confundir lo que es fácil de cuantificar con lo que es importante. Lo medible nos seduce justamente porque es medible, y terminamos optimizando para el número en lugar de para el resultado.
Y hay una ironía linda en todo esto, que conviene no perder de vista. Muchas de las personas que de verdad merecerían el rótulo de 10x —si insistiéramos en usarlo— no lo son por la cantidad de código que escriben, sino por cuánto elevan a quienes los rodean. El multiplicador real, cuando existe, casi nunca está en el output propio; está en el efecto sobre los demás. Pero ese efecto es justamente lo que las métricas individuales no ven, y por eso esas personas suelen pasar más desapercibidas que el que cierra muchos tickets ruidosamente. Premiamos el brillo visible y nos perdemos el multiplicador silencioso.
Después de años de mirar equipos por dentro, llegué a una conclusión que va a contramano de buena parte de la mitología técnica: las personas más valiosas de un equipo no son siempre las que más producen, sino las que hacen que el equipo entero produzca mejor. Y casi nunca son las mismas.
Pienso en esa persona que no es la más rápida escribiendo código, pero que desbloquea a tres compañeros por día respondiendo dudas, explicando una parte del sistema, evitando que alguien se meta en un pozo. En esa que documenta lo que nadie quiere documentar, que deja el camino allanado para el que venga después. En la que hace buenas revisiones, no para lucirse encontrando errores, sino para que el código que entra sea mejor y para que los demás aprendan en el proceso. En la que tiene la honestidad de decir “esto no lo entiendo” en una reunión, y al hacerlo le da permiso a otros cuatro que tampoco entendían para preguntar. Ninguna de esas contribuciones aparece bien en las métricas de productividad individual. Todas son, en mi experiencia, lo que separa a un equipo que funciona de uno que apenas sobrevive.
Hay una palabra que resume buena parte de esto y que en software solemos subestimar: coordinación. Gran parte de lo que hace o deshace a un equipo no pasa dentro de la cabeza de cada uno, sino en el espacio entre las personas: cómo se comunican, cómo se reparten el trabajo sin pisarse, cómo comparten lo que saben, cómo manejan los desacuerdos. Un equipo de cinco personas excelentes que coordinan mal rinde peor que un equipo de cinco personas buenas que coordinan bien. Lo vi tantas veces que ya dejó de sorprenderme, aunque sigue costándome convencer a otros de que es así, porque va contra la intuición de que basta con juntar a los mejores.
Lo que dice un libro de CEOs, y por qué me interesó#
Hace poco leí CEO Excellence, de Carolyn Dewar, Scott Keller y Vikram Malhotra, tres socios de McKinsey que entrevistaron a decenas de los CEOs más exitosos del mundo para entender qué los distinguía del resto. No es un libro sobre programación ni sobre equipos técnicos; es un libro sobre liderazgo al más alto nivel. Y sin embargo, varias de sus ideas me resultaron sorprendentemente aplicables a lo que veo todos los días conduciendo equipos de desarrollo, mucho más que muchos libros escritos específicamente sobre gestión técnica.
Una de las autoras lo resume en una frase que, cuando la leí, sentí que describía exactamente lo que me costó años entender. Dice, hablando de los grandes CEOs: “Muchos directores ejecutivos se concentran en conseguir líderes individuales que sean excelentes en sus roles. Los CEOs excelentes se concentran más en la dinámica entre ellos, en la psicología del equipo y en cómo trabajan juntos.” La traducción es mía, pero la idea está clarísima: el foco de los mejores no está en armar una colección de cracks, sino en cómo esos cracks funcionan como conjunto. Y en el libro hay otra formulación que va en la misma dirección, casi como un lema: los mejores piensan menos en qué hace el equipo en conjunto, y más en cómo trabaja el equipo en conjunto.
Me detengo en esa distinción —qué hace versus cómo trabaja— porque me parece la clave de todo. La mayoría de nosotros, cuando pensamos en mejorar un equipo, pensamos en el qué: qué tareas, qué tecnologías, qué objetivos, qué entregables. Es lo concreto, lo medible, lo que se pone en un tablero. El cómo —la dinámica, la confianza, la forma de comunicarse y decidir— es más difuso, más difícil de medir, y por eso lo descuidamos. Pero es ahí, según el libro y según mi experiencia, donde se juega la diferencia real. Los mejores líderes invierten en el cómo, aunque sea menos vistoso, porque saben que el qué se resuelve solo cuando el cómo está sano.
Un dato que me hizo ruido#
El libro trae un dato que me quedó dando vueltas, y que conviene mirar con cuidado porque es revelador. Cuentan que apenas alrededor del 6% de los altos ejecutivos de recursos humanos —gente cuyo trabajo, justamente, incluye cuidar que el trabajo en equipo funcione— está de acuerdo con que su propio equipo directivo opera como un equipo bien integrado. Y que cuando se les pide evaluar qué tan bien trabaja su equipo en relación con su potencial, lo puntúan apenas un cinco sobre diez. Estamos hablando de los equipos del tope de las organizaciones más grandes del mundo, gente con todos los recursos a disposición, y aun así la mitad del potencial de trabajo conjunto se está quedando sobre la mesa.
Los autores sacan una conclusión que para mí es el corazón del asunto: la razón de esas dificultades no suele estar en los miembros individuales del equipo, sino en la dinámica de cómo el equipo trabaja en conjunto. O sea, no es un problema de gente; es un problema de cómo esa gente funciona junta. Y si esto pasa en los equipos directivos de las empresas más poderosas, donde sobra talento individual, ¿por qué supondríamos que en nuestros equipos de desarrollo el talento individual alcanza? Si juntar gente brillante fuera suficiente, esos equipos del tope rendirían diez sobre diez, no cinco. Algo más está en juego, y ese algo es el cómo.
Llevarlo a nuestro terreno: del CEO al líder técnico#
Acá quiero hacer el ejercicio de traducir esto al mundo concreto en el que me muevo, porque una cosa es la idea elegante de un libro y otra es qué significa el lunes a la mañana frente a un equipo de desarrollo. Si los mejores líderes se enfocan en el cómo más que en el qué, ¿qué implica eso para alguien que conduce gente que escribe software?
Implica, para empezar, dejar de obsesionarse con encontrar y retener estrellas, y empezar a obsesionarse con cómo funciona el conjunto. No significa que el talento individual no importe —importa, y mucho— sino que no alcanza, y que muchas veces ni siquiera es el factor decisivo. Implica prestarle atención a cosas que el reflejo técnico tiende a ignorar: si la gente comparte lo que sabe o lo acapara, si hay confianza para decir “no sé” o todos disimulan, si las decisiones se discuten sano o se imponen, si el conocimiento está distribuido o concentrado en pocas cabezas. Implica valorar y hacer visible al que desbloquea a otros, al que documenta, al que enseña, aunque su nombre no aparezca primero en las métricas de output. Y, sobre todo, implica entender que mi trabajo como líder no es maximizar la producción de cada individuo por separado, sino diseñar las condiciones para que el equipo entero trabaje mejor en conjunto. Son dos trabajos distintos, y confundirlos lleva a optimizar lo que se ve a costa de lo que importa.
Cómo cambia esto a quién sumamos y a quién premiamos#
Esta forma de mirar tiene consecuencias muy concretas en dos momentos donde un líder técnico deja su huella más profunda: a quién suma al equipo y a quién reconoce una vez que está adentro. Si uno cree en el mito del 10x, contrata buscando al individuo más brillante posible, y evalúa después premiando al que más produce. Si uno entiende que el rendimiento es del conjunto, las dos cosas cambian.
En la contratación, dejé de preguntarme solamente “¿qué tan bueno es esta persona?” y empecé a preguntarme también “¿qué le va a hacer a la dinámica de este equipo?”. Hay gente técnicamente excelente que, sumada a un equipo, lo empeora: acapara conocimiento, desprecia a los demás, convierte cada discusión en una competencia. Y hay gente de habilidad más modesta que eleva todo lo que toca, porque genera confianza, comparte, destraba. Durante años contraté mirando casi solo la primera dimensión, la del talento puro, y aprendí a los golpes que un crack tóxico puede costar más caro que lo que aporta, porque el daño que hace al cómo del equipo se paga en todos los demás. Hoy le doy tanto peso a cómo alguien va a funcionar con otros como a qué tan bueno es a solas. No más, pero tampoco menos.
En la evaluación pasa algo parecido y, si se quiere, más delicado, porque es donde más fácil es equivocarse sin darse cuenta. Si solo premio output visible, le estoy mandando al equipo un mensaje clarísimo: lo que importa es tu producción individual, no lo que hacés por los demás. Y la gente, razonablemente, responde a los incentivos: si ayudar al otro no se reconoce, ayudar al otro se vuelve tiempo perdido. Así, sin querer, un sistema de evaluación mal pensado puede destruir exactamente el cómo que tanto nos cuesta construir. Por eso trato de hacer visible y de valorar explícitamente lo que no aparece en las métricas: la mentoría, la documentación, las buenas revisiones, el desbloqueo silencioso. No porque sea simpático reconocerlo, sino porque si no lo reconozco, lo estoy desincentivando. Lo que un líder premia es lo que el equipo va a hacer más, y conviene tener mucho cuidado con qué estamos premiando sin darnos cuenta.
Sería deshonesto presentar todo esto sin reconocer sus matices, porque la idea, llevada al extremo, también tiene riesgos, y no me gustan los posts que defienden una tesis sin mirarle las costuras. Hay un peligro real en sobrecorregir: en nombre del “trabajo en equipo”, se puede caer en el exceso de reuniones, en la dilución de responsabilidades, en el consenso permanente que no decide nada, en castigar implícitamente al que rinde mucho para no “romper la armonía”. El equipo como excusa para la mediocridad es tan dañino como la estrella como excusa para la fragilidad. No estoy proponiendo eso, ni cerca.
El propio libro, de hecho, no plantea que el cómo reemplace al qué, sino que lo potencia. Un equipo que trabaja bien en conjunto pero no tiene gente capaz no llega a ningún lado; la dinámica sana no compensa la falta de competencia. La idea no es elegir entre talento individual y trabajo en equipo, sino entender que el segundo es lo que permite que el primero rinda de verdad. Una estrella en un equipo disfuncional brilla poco y dura menos; la misma estrella en un equipo que coordina bien multiplica su impacto y, de paso, eleva a los demás. El talento individual es el combustible; el cómo trabaja el equipo es el motor. Sin combustible no andás, pero el combustible sin motor tampoco te lleva a ningún lado. El error histórico de nuestra industria fue enamorarse del combustible y descuidar el motor.
Lo que cambió en mí#
Si miro hacia atrás, el cambio más grande en mi forma de liderar no fue aprender una metodología nueva ni dominar una herramienta. Fue correr el foco. Pasé de preguntarme “¿cómo consigo y retengo a los mejores individuos?” a preguntarme “¿cómo hago para que este grupo de personas, con sus virtudes y sus límites, trabaje mejor en conjunto?”. Parece un cambio chico, casi semántico, pero en la práctica reordena todo: qué mirás, qué premiás, en qué invertís tu tiempo, qué considerás un problema y qué considerás un éxito.
Y descubrí algo que no esperaba: cuando el cómo está sano, el talento individual florece más, no menos. La gente buena rinde mejor en un equipo que funciona, porque no tiene que pelear contra la fricción, porque confía, porque puede concentrarse en lo suyo sabiendo que el resto está cubierto. Cuidar el cómo no es bajar la vara del talento; es crear el suelo donde el talento puede crecer. Por eso me resulta tan valioso que un libro sobre los CEOs más exitosos del mundo termine, después de cientos de entrevistas, en la misma conclusión a la que llegué yo a los tropezones desde un lugar mucho más humilde: que lo que distingue a los grandes no es rodearse de individuos brillantes, sino lograr que trabajen brillantemente juntos.
Les dejo una pregunta para que la lleven a su propio equipo, porque creo que el reflejo del 10x está más metido en todos nosotros de lo que admitimos. La próxima vez que evalúen quién es la persona más valiosa de su equipo, ¿van a mirar quién produce más, o quién hace que todos los demás produzcan mejor? Porque casi nunca son la misma persona, y la diferencia entre reconocer a una o a la otra dice más sobre la madurez de quien lidera que sobre el talento de quien es reconocido.
Fuentes consultadas#
- Carolyn Dewar, Scott Keller y Vikram Malhotra, CEO Excellence: The Six Mindsets That Distinguish the Best Leaders from the Rest, Simon & Schuster, marzo de 2022.
- McKinsey & Company, “Quote of the Day — Carolyn Dewar on CEO Excellence”, 1 de marzo de 2022.
- Extracto de CEO Excellence publicado en “CEO Excellence: Make Your Team the Star”, StartupNation, marzo de 2022.