Diferentes ingenieros. Diferentes habilidades. Diferentes valores.
Avi Siegel. Coalición de productos 6 de diciembre 2024. MEDIUM
Nuestro proyecto está retrasado. Su equipo de ingeniería se ha retrasado en la entrega de esa nueva característica fundamental.
Acude a una reunión de seguimiento con su jefe, temeroso de cuál podría ser el resultado de la conversación. Después de todo, simplemente no tiene suficientes recursos para lanzar la función antes.
Empiezan a hacerse cálculos mentales. El jefe se anima: aparentemente, el equipo D puede soportar perder a un par de desarrolladores; de todos modos, su trabajo es menos importante.
Acabas de recibir 2 nuevos recursos. Es raro, pero sucede.
No importa el hecho de que ellos son ingenieros back-end y el tuyo es una función pesada en el front-end.
No importa el hecho de que uno de ellos todavía está en la fase de nueva contratación, quitándole a los ingenieros con experiencia más capacidad de entrega de valor del que ellos aportan.
No importa el hecho de que el otro tiene un historial de ser, digamos, maravillosamente hábil para convertir cada requisito en un debate interminable.
No importa el hecho de que cuando comiencen a trabajar en el proyecto, tendrás que tenerlo listo.
Lo único que importa es que tienes que gestionar dos nuevos ingenieros en este proyecto. Dos ingenieros que no encajan en el rompecabezas. Dos ingenieros que ralentizarán el trabajo mucho más de lo que pueden acelerarlo.
Y ahora tienes que hacerlo de alguna manera más rápido .
¡Qué mal uso de los recursos!
¿Por qué sigue pasando esto?
El mito persistente de la fungibilidad de los ingenieros sigue atormentando a las empresas de software, tanto grandes como pequeñas. Nos lleva a todos a una mala formación de equipos, a expectativas desalineadas y, en última instancia, a demoras en la entrega y a una desaceleración de la creación de valor.
Es hora de dejar de lado esta fantasía y reconocer la realidad: los ingenieros de software no son engranajes intercambiables en su máquina de desarrollo.
No existe un “ingeniero que los gobierne a todos”
No es difícil ver cómo llegamos aquí.
Más abejas obreras = más zumbido = más miel más rápido = más ingresos dulces.
Pero esto fracasa por varias razones.
- Diferentes humanos tienen diferentes habilidades
- Diferentes seres humanos tienen diferentes niveles de habilidad en las habilidades en las que son expertos.
- Cada ser humano tiene distintas formas de utilizar sus habilidades.
Vamos a profundizar más.
1. Diversos conjuntos de habilidades
El desarrollo de software moderno requiere una amplia gama de conocimientos y habilidades especializadas. Así como un hospital necesita distintos tipos de médicos, una organización de ingeniería exitosa necesita varios especialistas técnicos.
Por ejemplo:
Ingenieros de interfaz que comprenden en profundidad las peculiaridades de los navegadores y la experiencia del usuario . Conocen las complejidades de los canales de renderizado y pueden crear aplicaciones de alto rendimiento que funcionan en infinitas combinaciones de dispositivos y navegadores (aunque, afortunadamente, ya no existe IE6).
En empresas como Figma o Notion , estos especialistas son la diferencia entre una aplicación web poco práctica y una experiencia nativa.
Ingenieros de back-end que se destacan en el diseño y la escalabilidad de sistemas . Entienden los sistemas distribuidos , pueden diseñar soluciones que gestionen millones de solicitudes y saben cuándo elegir entre diferentes bases de datos y estrategias de almacenamiento en caché.
Cuando Stripe procesa miles de millones de dólares en pagos o Netflix ofrece millones de transmisiones simultáneas, son estos especialistas quienes lo hacen posible.
Ingenieros de DevOps que viven y respiran infraestructura e implementación. Son los arquitectos de todo el proceso de entrega . Comprenden los matices entre los proveedores de la nube, saben cómo optimizar los costos de infraestructura manteniendo la confiabilidad y pueden crear sistemas de autorreparación que los despierten menos a las 3 a. m.
Las empresas modernas como Spotify confían en estos especialistas para crear canales de CI/CD extraordinarios que garantizan muchos nueves de tiempo de actividad , sin ninguna de esas ventanas de mantenimiento programadas que solías estar acostumbrado a ver en Internet.
Expertos en seguridad que detectan vulnerabilidades que otros podrían (o no ) pasar por alto. En un mundo en el que una sola infracción puede destruir el valor de una empresa de la noche a la mañana, estos especialistas comprenden vectores de ataque cuya existencia la mayoría de los ingenieros ni siquiera saben.
Pueden detectar vulnerabilidades de inyección SQL en consultas aparentemente inocentes, comprender las implicaciones de diferentes esquemas de autenticación y saber cómo construir sistemas que sean seguros por diseño y no como una ocurrencia de último momento.
En empresas como Okta, estos especialistas son la diferencia entre una plataforma de identidad segura y una violación masiva de datos; en Cloudflare, son responsables de proteger millones de sitios web de sofisticados ataques DDoS y amenazas emergentes.
Expertos en el área que comprenden no solo el código, sino también el contexto empresarial. En el ámbito de la tecnología financiera, estos son los ingenieros que comprenden las regulaciones bancarias y las redes de pago. En el ámbito de la atención médica, conocen a la perfección el cumplimiento de la HIPAA.
En empresas como Plaid o Epic Systems , estos especialistas traducen los complejos requisitos de la industria en soluciones técnicas que realmente funcionan en el mundo real.
Y luego están los ingenieros de la nube, los ingenieros móviles, los ingenieros de IA, los expertos en blockchain, los científicos de datos, los desarrolladores de bases de datos, etc. Y ni siquiera mencionamos todos los diferentes lenguajes, sistemas y plataformas de desarrollo.
Intentar que todos los ingenieros sean generalistas es como pedirle a un cirujano cardíaco que también sea un gran pediatra, ginecólogo, reumatólogo, neurólogo y oftalmólogo: el resultado será mediocre en todas las áreas. Cada especialización representa años de conocimiento acumulado que no se puede replicar leyendo algunos tutoriales o tomando un curso intensivo.
2. Diferentes niveles de habilidad
No sólo cada persona tiene distintos años de experiencia, sino que esos años tampoco se traducen directamente en capacidad de la misma manera. Depende de dónde trabajaron, cómo trabajaron, cuán duro trabajaron, cuán difícil fue el trabajo, con quién trabajaron, etc. También depende de cómo aprendieron, cuán rápido aprendieron, de quién aprendieron, etc.
Dicho esto, una vez que se convierte el currículum de cada ingeniero en una clasificación por función o título, existen diferencias clave en lo que podrán lograr para la empresa.
Los ingenieros jóvenes necesitan una tutoría estructurada y revisiones periódicas del código para desarrollar buenas prácticas. Se destacan en tareas bien definidas, pero tienen dificultades con los problemas ambiguos. Pueden avanzar con lentitud y cuidado, o en otras ocasiones, con más rapidez de lo esperado, aunque dejan una carga de deuda técnica a su paso.
Los ingenieros de nivel medio son ejecutores constantes. Pueden encargarse del desarrollo de funciones con una supervisión mínima y manejar la mayoría de las decisiones técnicas diarias de forma independiente. Saben cuándo levantar la mano para hacer preguntas .
Los ingenieros senior comienzan a aportar valor multiplicador. Pueden tomar decisiones arquitectónicas que afectan la capacidad de mantenimiento a largo plazo. Pueden asesorar a otros mientras realizan su propio trabajo de circuitos integrados. Pueden identificar y resolverproblemas potenciales antes de que se conviertan en problemas activos .
Los ingenieros principales o de planta pueden diseñar estrategias técnicas para varios equipos o incluso para toda la organización. Pueden prevenir categorías enteras de problemas mediante una intervención temprana. Saben dónde están enterrados los cadáveres, saben mejor cómo trabajar en torno a ellos y comprenden cuándo es el momento adecuado para exhumarlos .
Comprender estas distinciones no tiene que ver solo con los títulos o la remuneración, sino con la creación de equipos que puedan entregar y mantener eficazmente sistemas complejos a lo largo del tiempo. Tratar a un ingeniero junior como si fuera senior lo abrumará; tratar a un senior como si fuera junior lo alejará.
3. Diferentes formas de trabajar
Cada ingeniero tiene una caja de herramientas mental única, moldeada por sus experiencias, educación e inclinaciones naturales. Estas diferencias en el enfoque pueden ser su mayor activo… o su mayor desafío.
- Algunos se destacan por sus soluciones rápidas e iterativas , mientras que otros brillan con un diseño cuidadoso y anticipado.
- Algunos requieren la máxima eliminación de la ambigüedad y el riesgo (y la ansiedad), mientras que otros prosperan con tareas más abiertas.
- Algunos entienden intuitivamente las implicaciones comerciales de las decisiones técnicas (y disfrutan de estar más involucrados en discusiones de alto nivel), mientras que otros prefieren dejar eso en manos del equipo de producto para que lo resuelva con el liderazgo y los equipos GTM.
- Algunos pueden justificar y equilibrar eficazmente la deuda técnica en el camino hacia el MVP , mientras que otros se inclinan más hacia la perfección (o imperfección) (para ser claros, ninguna de estas es necesariamente incorrecta; todo depende bastante de la situación).
- Algunos son mejores a la hora de hacer las preguntas correctas , mientras que otros son mejores a la hora de tener las respuestas (u opciones) correctas.
Esta diversidad de enfoques para la resolución de problemas es una fortaleza , no una debilidad : solo hay que saber cómo (y estar dispuesto a) aprovechar esas diferencias técnicas.
Sin embargo, esta mentalidad persiste.
A pesar de las numerosas formas en que distintos ingenieros pueden aportar valor distinto a distintos equipos, los líderes y gerentes de las empresas siguen tratándolos como si fueran uno solo.
¿Por qué?
Para ser completamente sincero, no creo que se trate de una falta total de consideración hacia los demás seres humanos. Cuando las personas están demasiado alejadas del problema, simplemente no comprenden los detalles suficientes como para formular una solución válida.
Y luego, todo y todos hacen que sea muy fácil tratar a un ingeniero exactamente igual que a otro:
- Las partes interesadas no técnicas, que simplemente no entienden el desarrollo de software, presionan al equipo y a la empresa para que avancen (a veces incluso ofrecen amablemente más ingenieros, como si el mítico mes del hombre no existiera).
- Las noticias tecnológicas siguen promocionando lo fácil que es para cualquiera crear cualquier producto imaginable (estamos cerca de lograrlo, seguro, pero lo siento, al menos por ahora, las herramientas sin código y la IA solo pueden llevarte hasta cierto punto; impresionante, sí; capaz de construir «por sí solo» la totalidad de tu próxima idea de producto de mil millones de dólares, no tanto)
- La gente cree que los buenos ingenieros pueden aprender cualquier cosa rápidamente (y claro, tal vez los mejores puedan hacerlo), pero ¿quieres que tus ingenieros pasen todo su tiempo aprendiendo una nueva habilidad o usando activamente las habilidades que ya tienen?
- Las herramientas de gestión de tareas reducen todo el trabajo a una única medida de esfuerzo (por ejemplo, puntos u horas) y luego miden la eficiencia utilizando esa misma métrica (por ejemplo, 30 puntos por sprint ), sin ayudar a nadie a ver qué tan productivo es el equipo al generar valor en forma de resultados , y tampoco ayudan a planificar la capacidad considerando las capacidades individuales (para que conste, esto es algo en lo que estoy trabajando ).
La mentalidad de los engranajes de una máquina persiste porque ofrece respuestas simples a problemas complejos (y, al fin y al cabo, el liderazgo quiere un número, no una conversación). El problema es que las respuestas son erróneas (o, en el mejor de los casos , incompletas) y la simplicidad es engañosa.
Construir equipos que realmente trabajen (juntos)
La clave del éxito no consiste, evidentemente, en tratar a los ingenieros como si fueran iguales. En lugar de ello, hay que tener en cuenta el valor único que aportan y aprovecharlo creando equipos que aprovechen las fortalezas individuales y compensen las debilidades.
1. Evalúe la idoneidad del ingeniero, no solo sus habilidades
Encontrar al ingeniero adecuado no consiste simplemente en marcar una lista de requisitos técnicos, sino que requiere una evaluación matizada de cómo sus capacidades únicas se adaptarán a su equipo y a sus desafíos particulares.
- Mire más allá de las habilidades técnicas genéricas y busque experiencia y conocimientos específicos.
- Considere la dinámica del equipo y los estilos de comunicación.
- Evaluar la adecuación cultural , en particular sin exigir ni esperar conformidad.
- Evaluar el estilo de aprendizaje y la capacidad de adaptación
- Mapear las fortalezas individuales con las necesidades específicas del proyecto
El objetivo no es encontrar “los mejores” ingenieros, sino los ingenieros adecuados para sus necesidades y contexto específicos.
2. Crear equipos equilibrados y complementarios
Construir un equipo de ingeniería eficaz (léase: productivo, no eficiente ) es más arte que ciencia.
Los chefs combinan sabores en comidas dignas de estrellas Michelin, los compositores arreglan instrumentos en hermosas producciones sinfónicas y los líderes de ingeniería combinan diferentes fortalezas y estilos técnicos en un todo cohesivo que puede construir el producto que necesita construirse.
- Combinación de expertos en el dominio con experiencia y estudiantes entusiastas
- Emparejar a personas con diferentes enfoques de resolución de problemas.
- Garantizar la cobertura de habilidades críticas y al mismo tiempo dejar espacio para el crecimiento
- Equilibre a los especialistas técnicos con generalistas fuertes
- Crear oportunidades de transferencia de conocimientos y tutoría.
Los equipos de alto rendimiento no se construyen recopilando copias exactas: se construyen combinando fortalezas complementarias.
3. Transformar la diversidad en resultados
La creación de equipos diversos es solo el principio. Para liderar con éxito esos equipos hacia la creación de valor de manera eficiente y productiva se requiere un enfoque de gestión que acepte y aproveche las diferencias en lugar de intentar normalizarlas.
- Proporcione a los ingenieros problemas que coincidan con sus puntos fuertes: no obligue a los especialistas en ingeniería financiera a diseñar su esquema de base de datos solo porque «un ingeniero es un ingeniero».
- Establecer expectativas basadas en capacidades individuales en lugar de en una “capacidad de ingeniería” genérica: más difícil, sí; más preciso y útil, también sí
- Construya trayectorias profesionales que valoren tanto la profundidad como la amplitud de la experiencia, y no obligue a los empleados a pasar a la gerencia solo para ganar más dinero , lo único que hace es intercambiar una buena velocidad de ingeniería por un liderazgo deficiente (si quieren hacer ese cambio, esa es, por supuesto, una historia diferente).
- Fomentar un entorno en el que las diferencias de enfoque se consideren activos, no pasivos; en otras palabras: colaborar.
Cada ingeniero tiene un superpoder único (o varios, si tienes suerte). Tu trabajo es crear las condiciones para que puedan usarlo mejor.
Una máquina mejor
La próxima vez que alguien sugiera tratar a los ingenieros como recursos intercambiables (engranajes de una máquina de desarrollo de productos), sea la persona sensata en la sala que sabe que eso simplemente no es cierto.
Los ingenieros no son todos un montón de procesadores idénticos e intercambiables en un enorme clúster informático. Son más bien como un equipo deportivo profesional, donde cada jugador aporta habilidades y puntos fuertes únicos al juego.
Tu trabajo no consiste en encajar piezas de ingeniería cuadradas en agujeros de ingeniería redondos , sino en formar un equipo en el que se combinen distintas habilidades y perspectivas para crear algo mayor que la suma de sus partes.
Así que deje de asumir que todos los ingenieros son fungibles en sus sistemas de gestión de tareas, ceremonias de planificación de sprints , hojas de cálculo de planificación de capacidad y documentos de planificación trimestrales.
En lugar de ello, invierta en comprender y aprovechar las diferencias muy reales entre los seres humanos que componen sus equipos de ingeniería.
