Ingeniería sin ego: lecciones e ideas
Introducción
- En la industria tecnológica, el ego y el parroquialismo (faccionalismo) suelen ser factores principales que obstaculizan el trabajo en equipo
- Comparto algunas ideas surgidas de pensar cómo hacer que los equipos de ingeniería sean más eficientes y colaborativos
El dilema de repartir responsabilidades
- Incluso con solo dos empleados, repartir el trabajo es indispensable
- Sin embargo, la forma de repartirlo puede tener efectos inmediatos y de largo plazo
- Muchas empresas no reflexionan a fondo sobre este problema
La realidad de las ciencias de la computación
- Muchas personas de ciencias de la computación descubren más tarde que en realidad entraron a una disciplina relacionada con el trabajo abstracto matemático
- Ese choque inicial hace que a lo largo de la mayor parte de su carrera eviten aplicar lo aprendido a ámbitos fuera de la computación
- Si pensaran el entorno de trabajo con la misma profundidad que su enfoque técnico, habría espacio para mejorar
Patologías organizacionales y experiencias
- Incluso las empresas exitosas difícilmente evitan las patologías organizacionales, y también se puede aprender de ellas
- Caso de una startup donde el autor pasó el inicio de su carrera:
- Aunque la empresa aún era pequeña y estaba en una etapa temprana, ya había adoptado una estructura excesivamente burocrática
- Agregó un "middleware en Python" basado en una teoría equivocada de que aceleraría las solicitudes web
- Como resultado, se generaron más saltos de red y el rendimiento empeoró
- Para lanzar una sola función era necesaria una colaboración compleja entre varios roles
- El personal de base de datos escribía DDL y desarrollaba procedimientos almacenados
- Los desarrolladores de Python trabajaban en un middleware ineficiente
- Los desarrolladores de PHP escribían el código del frontend
- Debido a esta estructura de división del trabajo, no se lanzó ni una sola función nueva en dos años
- Resultado
- Como consecuencia de la estructura ineficiente y del flujo de trabajo, despidieron a todo el personal
- A mí no. Sobreviví por quejarme
El problema de la especialización de roles en grandes empresas
- Contexto: trabajo en una empresa de productos B2B con más de 1,000 empleados
- Al principio operaba con una estructura de equipos funcionales claramente divididos (Feature Teams) y equipos de servicios compartidos (operaciones, DBA, etc.)
- Al principio parecía una estructura normal
- Con el tiempo, los roles se fragmentaron en exceso y aumentó la ineficiencia
- Se añadió un nuevo rol llamado "Release Manager" para gestionar los lanzamientos
- La razón para agregar roles no estaba clara, y la estructura organizacional se volvía cada vez más compleja
- Ejemplos del problema:
- A los ingenieros de frontend se les limitaba a trabajo de frontend, y a los de backend a trabajo de backend
- Esa separación podía sostenerse, pero la política de dejar todo el trabajo de seguridad al equipo de seguridad provocó problemas graves
- Resultado: al identificar los roles con el trabajo mismo, se terminó dañando la eficiencia organizacional
- Surgieron falta de colaboración entre equipos y duplicación de trabajo
Portafolio de productos disperso y ausencia de una estructura de supervisión
- Trabajo en una empresa que desarrolla principalmente aplicaciones cliente nativas
- Al principio tenía una aplicación cliente principal exitosa, pero en la década de 2020 avanzaban en paralelo proyectos dispersos e inconsistentes
- Problemas en la gestión del portafolio de productos
- La estructura de supervisión del conjunto de productos era débil
- No había ninguna coordinación entre productos en el stack tecnológico ni en la toma de decisiones
- Cada equipo de producto reportaba de manera independiente al CEO, y el CEO no hacía esfuerzos de coordinación
- Intento de construir una función operativa compartida
- Surgieron dificultades porque el grupo de operaciones no participaba en el proceso de decisiones de arquitectura
- El equipo de operaciones estaba demasiado ocupado administrando cientos de servicios usados históricamente por los equipos de desarrollo como para participar en decisiones importantes
- Esto puede verse como un ejemplo típico de ineficiencia organizacional
[Generalizar los patrones de problemas organizacionales]
Patrón 1: confundir roles con trabajo
- Existe una tendencia a crear una nueva descripción de puesto para cada nueva tarea
- Ejemplo: aunque un ingeniero existente podría encargarse del trabajo relacionado con IA, se crea un nuevo rol de ingeniero de IA
- Esto provoca conflictos dentro de la organización y puede debilitar la motivación del equipo actual
- Esta separación excesiva de roles genera una burocracia innecesaria
Patrón 2: distribución incompleta de la revolución DevOps
- Muchas empresas afirman que "implementaron DevOps", pero en la práctica la división del trabajo y los conflictos siguen presentes
- Las fronteras claras entre operaciones y desarrollo, o entre SRE y desarrollo, obstaculizan la colaboración
- El propósito original de DevOps era derribar esas fronteras mediante colaboración y empatía, pero rara vez se materializa en la realidad
Patrón 3: los límites de una división rígida del trabajo
- Descomponer y especializar el trabajo puede parecer obvio para quienes lideran
- Ejemplo: el trabajo de IA queda a cargo de especialistas en IA, y las operaciones a cargo del personal de operaciones
- Pero esa estructura crea cuellos de botella
- Los ingenieros adicionales intentan aumentar la velocidad generando nuevas tareas, pero como resultado el tiempo de espera para análisis crece de forma no lineal
- Cuando los científicos de datos o los recursos de análisis llegan a su límite, todo el proceso se ralentiza
Patrón 4: una estructura organizacional equivocada genera trabajo extra
- Cuando los límites organizacionales no están claros o están mal definidos, aumenta innecesariamente la carga de trabajo
- Ejemplo: el equipo de seguridad se encarga de todos los problemas de seguridad y aparece una cola de tickets de seguridad
- El equipo de desarrollo avanza sin considerar la seguridad, y como resultado aumenta aún más el trabajo de seguridad
- A corto plazo esto puede ignorarse, pero a largo plazo se convierte en un problema serio
Patrón 5: sesgos humanos persistentes
- Existe la tendencia a sobrevalorar el propio rol y subestimar el de los demás
- Algunas personas juzgan erróneamente que el trabajo de servidores "no es técnico"
- A la inversa, también es común considerar que el trabajo de producto es menos técnico
- Esa actitud debilita la confianza entre equipos y obstaculiza la colaboración
- Un "personaje brillante y dogmático" no aporta valor real desde una perspectiva sistémica
- A menudo líderes y organizaciones evalúan erróneamente esa actitud como algo "inteligente" o "valioso"
[Faccionalismo y ego]
- El parroquialismo (Parochialism) y el ego (Ego) son causas principales de la ineficiencia dentro de las organizaciones
- Parroquialismo: actitud de no querer invadir el territorio ajeno o falta de curiosidad por el trabajo de otros
- Ego: el orgullo por el trabajo puede tener un efecto positivo, pero también puede manifestarse negativamente al defender territorios o subestimar la capacidad de otras personas
- Estos comportamientos instintivos generan falta de empatía y dificultan la colaboración
Un mejor ejemplo: experiencia en un equipo de ingeniería exitoso
- En una startup anterior, una estructura horizontalmente separada en "feudos" se simplificó y se reorganizó en equipos más pequeños
- Líderes que se tomaron DevOps en serio derribaron barreras y promovieron la colaboración
- A lo largo de unos dos años de "destrucción creativa", todos los integrantes del equipo participaron en distintos tipos de trabajo
- Como resultado, se recuperaron la estabilidad de la infraestructura y la capacidad de lanzar software
- Después de la reorganización, el equipo de ingeniería ganó tiempo y autonomía
- A partir de eso, discutieron cómo aprovechar las capacidades adicionales del equipo
Propuesta 1: gran refactorización (Proposition 1: Boil the Ocean)
- A menudo los equipos usan sus recursos disponibles para refactorizar por completo las partes que no les gustan
- Pero ese método ya se había intentado y no era popular
Propuesta 2: actividades de "autoexhibición" (Proposition 2: Dress Like Big Dorks)
- Se intentó usar el tiempo ocioso del equipo para reforzar la cultura del grupo, por ejemplo creando merchandising
- Sin embargo, esto no servía como estrategia principal
- El incidente decisivo: un error de build de una diseñadora
- Una noche, una diseñadora rompió el build y el equipo tuvo que restaurarlo
- Al principio surgió la idea de separar con más claridad los roles entre diseñadores y programadores
- Pero una persona del equipo tomó la decisión audaz de darle directamente la clave de despliegue a la diseñadora
- Resultado:
- La diseñadora empezó a participar en el trabajo de código y mejoró el nivel de colaboración
- El equipo construyó monitoreo, suites de pruebas, etc., para crear un entorno de trabajo seguro
- La eficiencia y la productividad mejoraron mucho
Propuesta 3: fortalecer a los demás equipos (Proposition 3: Empower Everybody Else)
- Se adoptó una estrategia de usar los recursos disponibles del equipo para apoyar y fortalecer a otros equipos
- Aplicable tanto a equipos técnicos como no técnicos
- Esto promovió la colaboración en toda la organización y llevó a una ejecución más efectiva
Voluntad de llevarlo a la práctica
- Después del caso de la diseñadora, al colaborar con varios grupos se vivieron éxitos similares
- Se usó el tiempo libre del equipo y el poder organizacional disponible para ayudar a que cada equipo pudiera colaborar eficazmente
- La ejecución exitosa se basó en la colaboración y la empatía a nivel de toda la empresa
[Cómo se siente una ejecución exitosa]
- Especialistas vs. propietarios
- El equipo tenía especialistas de dominio, pero no "propietarios" de tareas o dominios específicos
- Caso de seguridad: en lugar de que el equipo de seguridad resolviera todos los problemas, todo el equipo asumía la seguridad y el equipo de seguridad se enfocaba en elevar las capacidades de los demás integrantes
- Este modelo debió haberse aplicado también en otras áreas, pero la mayoría de los equipos no lo logró
- Casos de fracaso
- Separar estrictamente a los ingenieros de frontend y backend
- La falta de colaboración llevó a complejidades innecesarias como GraphQL
- Se necesitan especialistas para ciertos roles, pero dividir los títulos en "frontend" y "backend" es ineficiente
- Principio central:
- "Especialistas de dominio, no propietarios"
- Se promueve que los especialistas tengan tiempo para ayudar a otros miembros del equipo además de su propio trabajo
Fomentar la colaboración proactiva
- Dar tiempo disponible
- Para mantener el trabajo en equipo a nivel general, se da a los integrantes tiempo disponible
- En lugar de esperar simplemente a que la colaboración surja de forma natural, se inyecta energía al sistema de manera intencional
- Seguridad psicológica y ampliación del grupo propio
- Las personas sienten seguridad psicológica dentro del grupo al que pertenecen, y desde ahí experimentan o aprenden cosas nuevas
- Se invierte tiempo y recursos para ampliar el "grupo propio" de los integrantes
- Bootcamp: hacer que trabajen temporalmente en otros equipos para darles oportunidades de colaboración
- Hackatón: se usa como evento con un efecto similar
Valores deliberados de equipo
- Definir la filosofía y los principios del equipo
- Se definen con claridad los objetivos más altos de actividades como revisión de código, bootcamps y hackatones
- Se declara que el elitismo es veneno
- Se fomenta una cultura donde todas las personas "resuelven directamente el trabajo que hace falta"
- Confianza mutua y expectativa de mejora
- Se establece una fuerte expectativa de dejar siempre en mejor estado el trabajo ajeno cuando se interviene en él
- Esa cultura anima a las personas del equipo a colaborar con gusto
Reflexiones finales
- Problemas de la industria tecnológica: elitismo y liderazgo dogmático
- Los líderes dogmáticos sin humildad obstaculizan la colaboración del equipo y fomentan una crueldad innecesaria
- La industria tecnológica suele confundir a esos líderes dogmáticos con figuras útiles, pero es un fenómeno parasitario y dañino
- No debería ser radical tratar a los demás con respeto, pero en la práctica lo es
- La colaboración trae mejores resultados
- La colaboración mejora los resultados, y la vida sin líderes dogmáticos es mejor
- Hace falta esforzarse por eliminar el faccionalismo y el ego
- La importancia de empoderar
- Para alentar a que las personas del equipo colaboren con curiosidad, hace falta el permiso y el apoyo del liderazgo
- Ejemplo: cambiar el trabajo de despliegue para que lo hagan directamente los desarrolladores y no SRE
- Al principio había preocupación por los errores de los desarrolladores, pero la mayoría resolvió los problemas por su cuenta y el cambio funcionó bien
- Los ingenieros de producto mostraron una actitud de querer resolver los problemas por sí mismos
- Dar slack al sistema
- Programas como bootcamps o hackatones requieren compromiso continuo
- Sin holgura en el sistema, esos programas tienden a desaparecer
- No hacemos funcionar las computadoras al 100%, pero tendemos a intentar eso con nosotros mismos
- La importancia de los valores y las recompensas
- Los líderes deben recompensar la colaboración y la curiosidad, e integrarlas en la cultura del equipo
- Los CEO a menudo intentan eliminar programas positivos (bootcamps, hackatones), pero hacen menos esfuerzo por eliminar programas negativos (revisiones de código obligatorias)
- Hay que abandonar la creencia equivocada de que el "dolor" produce resultados
- El dolor no es un buen indicador sustituto de resultados; la colaboración y la confianza generan un mejor desempeño
7 comentarios
> Para alentar a los miembros del equipo a colaborar con curiosidad, se necesita el permiso y el apoyo del líder.
¡Parece muy importante animar a las personas a interesarse con curiosidad por el área de sus compañeros de equipo, incluso si no es su propia área!
La realidad es...!
Parece una estructura imposible en una startup "wejail" donde te están presionando todos los días por el progreso..
Todos los que están en la operación deberían poder mantener el interés inicial de cuando entraron, pero por lo general no hay apoyo para ese aspecto, o es insuficiente.
Todo lo que dice es muy cierto... Pero la realidad es.................. T_T
¡Parece un texto realmente muy bueno!
Es un buen texto.
Opiniones de Hacker News
Existe la opinión de que es importante dejar el ego de los programadores fuera del desarrollo de software. Es deseable ver el producto de software como un logro del equipo a través del trabajo en conjunto.
Como lección aprendida a lo largo de una carrera en desarrollo, se aconseja no agregar procesos innecesarios, exigir sentido de pertenencia sobre el producto en todos los roles, evitar decisiones reactivas y fomentar la colaboración entre equipos.
Los mejores equipos están compuestos por equipos tipo pizza que son dueños de todo el stack y por especialistas que brindan asesoría cuando hace falta.
Aunque las metáforas deportivas no son populares en tecnología, existe la opinión de que la dinámica de los equipos deportivos se parece a la de los buenos equipos de negocios.
El éxito de una organización depende de que cada integrante actúe de forma altruista para satisfacer las necesidades del grupo.
Se enfatiza la importancia de establecer valores de equipo de manera intencional.
Trabajando en un área de growth, al principio el manager revisaba y fusionaba todos los commits, pero después se dio cuenta de que tenía permiso para desplegar a producción por cuenta propia.
Se prefiere a los expertos en dominio por encima de los dueños del dominio, y una especialización excesivamente explícita puede causar problemas.