Elogio del ingeniero "normal"

• El “ingeniero 10x” suena intuitivamente plausible, pero en la práctica es muy difícil medir la productividad de forma objetiva, y también es un enfoque equivocado verla como una característica personal inmutable
• La propiedad real y los resultados del software están determinados por la colaboración y la capacidad de un equipo de ingeniería
• Una organización realmente sobresaliente no es la que solo depende de personas excepcionalmente brillantes, sino la que crea un entorno donde los ingenieros normales producen buenos resultados de forma constante
• Los sistemas deben diseñarse considerando que la gente normal también se equivoca o se cansa, y el foco debe ponerse en construir "equipos 10x"
  • El diseño de sistemas de software y la cultura deben basarse en las características, la diversidad y el potencial de crecimiento de la "gente normal"
• En última instancia, el indicador clave de productividad es el impacto en el negocio, y lo importante no es contratar al “mejor talento”, sino formar equipos con las personas adecuadas

---

Elogio del ingeniero “normal”

• Este texto critica el concepto de “ingeniero 10x” y explica por qué son importantes las organizaciones donde ingenieros normales logran resultados de equipo extraordinarios

El mito del “ingeniero 10x” y sus límites

• Cualquiera ha tenido en su carrera la experiencia de encontrarse con un ingeniero extraordinario que parece un mago
• De ahí nació el concepto de “ingeniero 10x”, pero tiene poca base y además puede reforzar sesgos
• Es casi imposible definir una métrica única de productividad
  • La combinación de variables es infinita: stack tecnológico, dominio, etapa de desarrollo, situación del mercado, experiencia, etc.
  • Una persona puede ser un ingeniero 10x en un área específica, pero en la mayoría de las demás puede ser normal o incluso estar por debajo del promedio
• Aunque alguien haya sido un gran DBRE en algún momento, con el tiempo puede volverse normal en ese campo
• Al final, nadie puede ser 10 veces mejor en todo y siempre

La propiedad del software centrada en el equipo

• El software lo posee y lo gestiona un equipo, no una persona individual
• La entrega, el mantenimiento, la mejora, la expansión y el refactor del software ocurren como procesos de equipo
• Un sistema poseído por una sola persona se convierte en un single point of failure (SPOF) cuando esa persona sale de vacaciones o deja la empresa, y eso vuelve vulnerable a la organización
• En una startup, al inicio puede ser inevitable que haya propiedad individual, pero a medida que la organización crece, debe pasar sí o sí a propiedad de equipo
• La misión central del liderazgo de ingeniería debe ser enfocarse en crear equipos de alto desempeño; más importante que un “ingeniero 10x” es construir un equipo 10x

Qué necesita una organización de alto rendimiento de verdad

• Muchas empresas prefieren formar equipos con gente de FAANG, universidades de élite o perfiles Staff Engineer
• Pero una organización realmente buena es aquella donde un ingeniero normal puede generar impacto real de manera estable
• Más que una organización donde solo los “mejores” pueden rendir, la verdadera ventaja competitiva está en crear un sistema donde también desarrolladores comunes puedan crecer con iniciativa y tener un impacto positivo en el producto y el negocio
• De hecho, este tipo de organización forma a más ingenieros de clase mundial

Redefinir el significado de “normal”

• En la industria del software está muy extendida la mentalidad elitista de “top 10%” o “top .1%”
• Pero es importante reconocer que la gran mayoría de los ingenieros son personas normales que han crecido gracias a distintas experiencias y práctica
• Nadie nace siendo un “ingeniero brillante”
• Los grandes ingenieros se forman: cualquiera puede llegar a ser excelente mediante aprendizaje y experiencia

Diseñar sistemas para personas normales

• Al contratar, tiene sentido fijarse en fortalezas sobresalientes, pero al diseñar sistemas hay que considerar la realidad de que las personas, de manera normal, cometen errores, se cansan y se apoyan en lo familiar
• Un ingeniero común se ve afectado por sesgos cognitivos, fatiga y cambios emocionales
• Cuando el sistema está diseñado desde la perspectiva del ingeniero normal y no de una minoría especialmente brillante, el talento excepcional puede concentrar su creatividad en el producto mismo

Cómo construir un “equipo 10x”

• Reducir al mínimo la distancia entre escribir código y desplegarlo
  • Un ciclo de despliegue rápido reduce la carga cognitiva y permite experimentar y obtener feedback más rápido
  • Cuanto más lento es el despliegue, más cambios se acumulan a la vez, y más difícil se vuelve rastrear problemas y hacer rollback
• Hacer que la recuperación ante errores y el rollback sean fáciles
  • El desarrollador debe poder desplegar su propio código y, si detecta un problema, recuperarse rápidamente
• Hacer fácil lo correcto y difícil lo incorrecto
  • Colaborar con diseñadores e ingenieros de plataforma para construir guardrails y mecanismos de autoservicio
• Invertir activamente en observabilidad y herramientas de instrumentación
  • Visualizar el comportamiento real del código para que todos los ingenieros puedan entender y depurar el sistema con facilidad
• Invertir recursos de ingeniería en herramientas internas y mejora de la productividad
  • Estos sistemas necesitan ownership dedicado y deben convertirse en una prioridad para toda la empresa
• Fomentar una cultura inclusiva
  • Un entorno donde cualquiera pueda hacer preguntas, equivocarse y explorar
  • Los equipos con diversidad de orígenes, habilidades y años de experiencia son más resilientes y responden mejor al cambio
• Formar equipos con ingenieros de todos los niveles
  • Desde juniors hasta seniors, en una estructura donde aprenden, enseñan y crecen juntos
  • Este tipo de sistema también puede reutilizarse para onboarding de nuevos ingresos, movilidad entre equipos, etc.

La verdadera métrica de productividad: "impacto en el negocio"

• En última instancia, la métrica de productividad en ingeniería de software es el impacto en el negocio
• La esencia no está en escribir mucho código, sino en resolver problemas y crear valor
• En la práctica, quienes mueven la industria no son los ingenieros Staff+, sino los ingenieros senior y de nivel medio
  • Ellos forman la base de la organización y hacen avanzar el negocio de forma continua
  • Si solo el nivel Staff+ puede generar impacto, eso es una señal de que hay un problema en la organización

Organizaciones que forman ingenieros de clase mundial

• Una organización verdaderamente buena es aquella donde cualquiera puede generar impacto, incluso sin ser un ingeniero sobresaliente
• Las mejores organizaciones no necesitan contratar por separado solo al mejor talento del mundo; de forma natural son las que más ingenieros de clase mundial producen
• El talento se reúne donde los ingenieros pueden concentrarse en resolver problemas, crecer y generar impacto, y la experiencia misma de “trabajar feliz y crecer” impulsa un círculo virtuoso
• Los líderes no deben depender de la capacidad individual del talento excepcional, sino conectarla con el crecimiento de toda la organización y el valor para el cliente

Contratar a la “persona adecuada” antes que al “mejor talento”

• La industria insiste en buscar solo a “los mejores”, pero lo realmente importante es el sistema y el entorno
• Más que al “mejor talento”, la ventaja competitiva está en encontrar a la persona adecuada para el equipo y la organización
• Más que llenar el equipo de personas sin debilidades, es más efectivo construirlo con personas adecuadas que tengan fortalezas propias y que potencien la diversidad y la armonía de la organización
• Los equipos inclusivos y diversos son los que, en la práctica, impulsan resultados, crecimiento y éxito a largo plazo
• Un lugar donde todos disfrutan su trabajo, crecen y logran resultados significativos es la verdadera organización de clase mundial, y en una cultura donde también se puede aprender de los fracasos y errores, crecen tanto los ingenieros como la organización
• Ese tipo de organización es precisamente la que atrae a la próxima generación de ingenieros y también hace que el talento ya sobresaliente quiera quedarse

[GN⁺]

Opiniones de Hacker News

• Estoy de acuerdo con la idea de que la unidad mínima de propiedad y delivery de software es el equipo de ingeniería, pero me deja un poco insatisfecho. Esta estructura se conecta con una cultura donde los ingenieros terminan siendo ciudadanos de segunda frente a management o producto. Solo tenemos responsabilidad sobre el delivery, pero no podemos tomar de forma independiente decisiones realmente significativas más allá de un alcance muy pequeño dentro del equipo. En los mejores equipos, el horizonte de discreción llega a meses, incluso años, pero en la mayoría se reduce a días o semanas. Sin embargo, en la práctica sí es totalmente posible una estructura donde los ingenieros tengan propiedad real sin que el sistema se rompa ni se vuelva riesgoso a largo plazo. La clave es asegurar slack, fomentar trabajo de calidad y dar suficiente libertad para que cualquiera del equipo pueda cambiar de tareas con flexibilidad. Así, cada quien puede tener propiedad y tomar decisiones de largo plazo, mientras colabora ad hoc y comparte conocimiento tácito, de modo que también sea natural que alguien entre de repente a ayudar o incluso tome el relevo por completo. Por experiencia, estos equipos hacen más rewrites que un equipo común, pero en general son mucho más productivos. Reescribir gradualmente el sistema en partes pequeñas es muy efectivo tanto para la evolución del diseño como para acumular conocimiento y capacidades dentro de la organización. Aunque por fuera parezca desperdicio, es slack esencial para que toda la organización sea flexible y resiliente. De hecho, cada vez estoy más convencido de que muchos procesos top-down que supuestamente buscan reducir el desperdicio en realidad eliminan un slack muy importante

  • A la gente fuera de ingeniería muchas veces le cuesta evaluar directamente las decisiones de largo plazo que toman los ingenieros y no sabe qué recompensar. Esto pasa incluso fuera del mismo equipo de ingeniería. No tienen la capacidad de evaluar por sí mismos si un trabajo de largo plazo con valor interno realmente lo tiene o no. Si uno confía en su capacidad para tomar decisiones de largo plazo y usar bien el tiempo de slack, está bien recibir recompensas por el delivery. En algún momento, ese trabajo de largo plazo regresará en forma de mejores resultados

  • Creo que los rewrites de software cumplen un papel importante en el proceso de desarrollo. El verdadero “ágil” consiste en no obsesionarse demasiado con la arquitectura inicial, construir prototipos rápido y responder con flexibilidad a los cambios de requerimientos. Programar se parece a escribir: aunque el primer borrador sea tosco, suele ser mucho más eficiente simplemente avanzar y mejorar en una segunda versión. El objetivo del primer borrador no es que quede bien, sino construir algo rápido, explorar el espacio del problema y detectar edge cases. Esta forma de trabajar no suele funcionar bien con la gerencia. En cuanto muestras un prototipo funcional, dicen “saquémoslo ya” y no te dan tiempo para reescribirlo. Como solución, sería bueno aplanar la jerarquía de la organización y devolver de verdad la propiedad del código a los ingenieros. Lo ideal es una estructura donde ingenieros y product owners tomen decisiones juntos de forma democrática

  • Yo también valoraba mucho la “propiedad individual”, y todavía creo que los ingenieros pueden tener propiedad, pero también reconozco que muchos en realidad no la quieren. A la mayoría le parece bien si es a nivel de equipo, pero no les interesa tanto la propiedad al nivel de cada ingeniero. Es simplemente su trabajo. Si eso se deja a nivel individual, es fácil que se genere desconfianza dentro del equipo o que se excluya a quienes no tienen inclinación al liderazgo, y al final se termina en una situación donde nadie tiene discreción real. Dar propiedad y discreción al equipo como unidad es mucho más simple y efectivo. También es una dinámica posible gracias a que existe un líder o manager del equipo. Si se asigna la propiedad del software por persona, hay demasiados riesgos de falla por cambios de personal, estabilidad, carrera, etc. Por sana que sea una organización, siempre habrá problemas grandes y pequeños, y en este tipo de estructura el camino al fracaso se vuelve el más corto. Pensándolo como una caja de cambios se entiende fácil: si solo hay un engrane y se rompe, ya no avanzas; si hay varios, aunque sea incómodo, puedes seguir incluso si uno falla de inmediato

  • Sí creo que la propiedad individual real es posible. De hecho, me parece la única forma de ser de verdad “productivo”. Pero ese no es el punto esencial. Cada persona es insustituible, pero los miembros de un equipo pueden ser reemplazables hasta cierto punto dependiendo de la estructura. Cuanto más crece una organización, más busca previsibilidad a nivel equipo, y para eso necesita que los miembros sean reemplazables, es decir, redundancy. En ingeniería también se usa redundancy para lograr confiabilidad y resiliencia, y la eficiencia es un trade-off con reducir esa redundancy

  • Hemos trabajado en estructuras donde se supone que solo somos responsables del “delivery”, y al final la propiedad solo aumenta la carga sin ninguna recompensa real. El trabajo queda reducido a pegar features en una página. Si van a venir responsabilidades extra, también debería haber compensación extra. A managers y ejecutivos se les recompensa más según la cantidad de personas a su cargo; con los desarrolladores debería ser igual

• Estoy convencido de que los mejores equipos tienen una cultura que hace que ingenieros normales logren resultados enormes. Más que la llamada “calidad de ingeniería” o el reclutamiento de talento, importan mucho más la cultura, la confianza, los sistemas y los procesos. Se suele decir que “cualquiera puede construir una organización con los mejores ingenieros”, pero en realidad son muy pocas las que han creado equipos así. Casi todas son firmas de trading o grupos especializados/de investigación. Me pregunto por qué casi nadie más lo logra. Al final, ni siquiera está claro qué significa exactamente “productividad”. Hay sistemas de evaluación que en la práctica miden la capacidad de aguantar y atravesar la disfunción dentro de la organización, pero no creo que eso sea lo que realmente significa ser un ‘top engineer’

  • La oferta de ingenieros realmente sobresalientes es limitada, así que al final las empresas más grandes se los llevan ofreciéndoles trabajos más interesantes o salarios más altos

  • El tema del dinero que ya mencionaron otros importa mucho, pero el “tiempo” también pesa muchísimo. Las empresas no tienen margen para esperar hasta que aparezca el talento “unicornio” perfecto, así que terminan contratando deprisa a quien esté disponible. En algunas empresas, sobre todo en áreas como quant finance, un solo superingeniero que combine programación de sistemas, matemáticas y conocimiento de mercados financieros puede generar mucho más valor que un equipo de tres especialistas. Pero encontrar a alguien así toma demasiado tiempo. Incluso si solo ves desarrollo web, son poquísimos los verdaderos full-stack que entienden de verdad, de punta a punta, desde protocolos de red y administración de sistemas hasta sistemas distribuidos, bases de datos y frontend. Solo las organizaciones con suficiente tiempo y dinero pueden reunir este tipo de talento y construir el mejor producto. Claro, otra pregunta distinta es si el producto realmente necesita ese nivel de calidad

  • En el fondo, la oferta mundial de “mejores ingenieros” es extremadamente limitada. Si puedes pagar salarios del top 10% y además reunir y retener ese nivel de talento, entonces sí, vas a tener éxito. En realidad no es algo que “cualquiera” pueda hacer; de verdad se necesita liderazgo capaz de diseñar un sistema sociotécnico enfocado en aprendizaje y crecimiento. Eso por sí solo ya es un gran logro

  • El mayor problema es que la mayoría de los ejecutivos de primera y segunda línea no son tan buenos. Les falta capacidad para crear y mantener un entorno productivo. La solución de fondo, al final, es pagar mucho dinero. Si el dinero es suficiente, la mayoría puede tolerar condiciones difíciles

  • Más allá del presupuesto, una persona realmente brillante quizá ni siquiera sea tan buena para el trabajo en equipo. Una mente excepcional a veces puede ser un obstáculo para compromisos necesarios o para tareas aburridas pero importantes

• No puedo estar muy de acuerdo con la idea de que “el impacto de negocio es la única métrica de productividad”. Esa visión empuja la atención hacia cambios medibles y resultados de corto plazo, y hace que se pierda de vista el verdadero valor de un ingeniero experimentado. La verdadera habilidad está en evitar por adelantado los landmines que podrían haber arruinado un proyecto o una empresa. Pero ese tipo de “riesgo eliminado” es difícil de medir, y casi imposible de comunicar de una forma que no suene ordinaria

  • El “impacto” no tiene por qué verse solo en el corto plazo. Quien genera el máximo impacto en una organización actúa con perspectiva de largo plazo

  • Yo hablo de “productividad” o “impacto” a propósito como términos ambiguos. Por ejemplo: “viéndolo en general, X hizo un trabajo realmente bueno”. Son cosas difíciles de cuantificar o definir con precisión, pero en organizaciones complejas y creativas lo que más importa es la intuición y el juicio humano. Intentar forzar toda la gestión a números es, en el fondo, una visión miope

  • No estoy de acuerdo con medir el valor de un ingeniero solo por gestión de proyectos o evitación de riesgos, pero también me incomoda reducirlo todo a “impacto de negocio”. Hay muchas cosas valiosas para una persona, para la humanidad o para el mundo que no tienen nada que ver con dinero. Los ingenieros que más respeto no son las figuras míticas del Silicon Valley post-2001, sino John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, quien haya construido los acueductos romanos y las pirámides egipcias, o los astrónomos de Babilonia y Mesoamérica. ¿Dejaron impacto de negocio? Aunque Tesla alguna vez le haya dado ganancias a Westinghouse, eso no explica sus logros. De hecho, en términos de negocio fue bastante normal. Lo mismo vale para muchas grandes figuras de la industria moderna de la computación. Parte del enorme éxito de Nvidia o Geoff Hinton también tuvo que ver con la “suerte” de que internet se volviera publicidad y explotara la cantidad de datos. También hay muchos casos donde personas realmente brillantes quedaron relegadas y desaparecieron sin reconocimiento. Incluso alguien como Doug Lenat, una gran figura del AI, terminó sin ser redescubierto por cómo fluyó la historia. El éxito o fracaso muchas veces no tiene relación con el esfuerzo individual

  • Hay que elegir entre construir sistemas eficientes o construir sistemas que minimicen la posibilidad de desastre. En la práctica es difícil demostrar qué catástrofe se evitó, y como el impacto negativo es un “evento que no ocurrió”, cuesta muchísimo mostrarlo como resultado

  • Las empresas deberían esforzarse más por cuantificar el riesgo de lo “desconocido” de alguna manera

• He tenido la suerte de trabajar en varios equipos excelentes y ahora también lidero uno así. A diferencia de lo que dice el artículo, estos equipos suelen ser más difíciles de administrar dentro de la organización. Las organizaciones grandes tienden a enfocarse en la estandarización, y por eso muchas veces los ingenieros sobresalientes no pueden desplegar sus capacidades y pierden motivación. No comparto la visión pesimista de que no se puede formar a todas las personas para que lleguen a ser grandes ingenieros. En la práctica, con inversión constante sí se puede desarrollarlas, y creo que a largo plazo el beneficio de contar con un grupo más amplio de talento sobresaliente supera con creces el costo de esa inversión

• Que algo no pueda medirse de forma efectiva no significa que no exista. La productividad individual, es decir, el desempeño laboral de una persona, sí existe. Probablemente solo sea más fácil medir la productividad a nivel grupo. El “impacto de negocio” es en realidad mucho más arbitrario, y con una métrica así es muy difícil retener a la gente realmente productiva. Evaluar conocimiento especializado es muy difícil a menos que tengas experiencia equivalente; puedes dar consejos, pero otra cosa es que la otra persona tenga la apertura intelectual para aceptarlos. ¿Cómo saber si soy un genio o simplemente alguien demasiado seguro de sí mismo?

  • El problema no es que no podamos “medir” la productividad, sino que ni siquiera podemos “definirla” abstractamente. Aunque midas cuánto más aportó alguien en comparación con un replacement, eso no explica exactamente cómo se produjo ese resultado. En la práctica, la influencia individual está determinada por el contexto y por toda la organización. Incluso si intentas dar una definición más directa, la respuesta correcta cambia muchísimo según la organización y la situación. Vale totalmente la pena pensar en esto, pero también me pregunto si la propia idea del ingeniero ‘Top 1%’ tiene realmente sentido

  • Un verdadero genio puede explicar sus resultados con facilidad y con buenos modales. Por eso creo que sí se puede distinguir la diferencia

• Me gustó la frase “la mejor organización es la que permite que ingenieros normales hagan trabajo extraordinario”. No todos los miembros del equipo tienen que ser superestrellas. Lo realmente importante es qué tan bien está preparado el entorno para que un desarrollador promedio pueda rendir a un nivel suficientemente bueno y confiable

  • Todos los grandes ingenieros al principio solo eran buenos ingenieros. Una organización sana ayuda a que sus miembros recorran ese camino de crecimiento

• El principio de “hacer que lo correcto sea fácil y lo incorrecto difícil” suena igual al lema central de todos los equipos de plataforma que he conocido. El objetivo es diseñar sistemas donde la “respuesta correcta” a los problemas que enfrentan los ingenieros sea obvia y fácil de implementar. Si además tienen confiabilidad y facilidad de operación, la organización entera gana porque naturalmente desarrolla ese “músculo” de ingeniería. Esta verdad va a seguir vigente

  • Casualidad o no, Charity Majors escribió un excelente ensayo sobre esto. La idea es empezar formando un pequeño comité de ingenieros senior de confianza para crear una lista recomendada de componentes base para servicios nuevos. Eso se convierte en el “golden path”. La organización da soporte total solo a los componentes del golden path, cubriendo upgrades, parches, backups, despliegue, entornos, guardias on-call, etc. No es obligatorio usarlos, pero si eliges algo fuera del golden path, entonces te haces cargo absolutamente de todo

• Cada vez que salen mencionados golang, python, COBOL, lisp, perl, React, brainfuck y otros lenguajes/frameworks, desde hace tiempo siento que existe la tendencia a confundir React con todo el ecosistema frontend. En la práctica hay mucho mundo frontend más allá de React, pero pareciera que muchos creen que React lo es todo

• En nuestra empresa siempre preferimos contratar ingenieros promedio con buena actitud. La gente con grandes credenciales pero mala actitud suele saber manejar muy bien su reputación y ganarse rápido la confianza de los de arriba, y después se vuelve intocable. Cuando alguien así se consolida, a quienes están alrededor les cuesta muchísimo señalar problemas aunque se sientan perjudicados. Y la dirección también suele ignorar con facilidad los datos que contradicen su percepción. Es mucho más fácil apoyarse en percepciones que en datos objetivos

• De verdad conecté con la idea de que “cualquiera puede construir una organización que trabaje con los mejores ingenieros, y centrarse solo en la capacidad individual borra el rol real del liderazgo. Construir sistemas donde ingenieros menos experimentados puedan volcar sus capacidades y producir resultados es una ventaja competitiva enorme”. Yo no soy un ingeniero 10x, pero según mi experiencia reciente, cuando en el equipo hay mucha gente con poca experiencia o habilidad, termino siendo yo quien se hace cargo de los tickets complejos. Si ese patrón se repite, acabo haciendo yo solo la mayor parte del trabajo, y en la práctica ese rol es pesado y se siente injusto. Sinceramente, creo que un buen SRE debería tener incluso un poco de pereza, así que me gustaría que el equipo repartiera más el trabajo. Por eso trabajé muy duro durante varias semanas e introduje varias abstracciones en las partes más complejas (yo trabajo principalmente con IAC; en software se ve un patrón similar). Entonces los ingenieros con menos habilidad o experiencia también pudieron asumir parte de mi rol, y yo pude dedicar mi tiempo a problemas más interesantes. Fue la primera vez que intenté algo así sin que nadie me lo pidiera. En cambio, si no existe esa estructura y uno actúa como héroe en solitario, todo el equipo termina corriendo detrás, arreglando errores, y al final se vuelve un equipo realmente ineficiente