Creando equipos autosuficientes
No se trata de tener a los mejores, sino de que tengan autonomía.
¡Hola! Cuando dejé mi anterior empresa, Epos Now, el 31 de Diciembre de 2024, tuve que prepararme para pasar por varios procesos de selección — al final no fueron muchos — así que me puse a organizar ideas y procesos que había puesto en práctica los últimos años como Director de Ingeniería. Se me ocurrió entonces retomar (o mejor dicho recomenzar) la newsletter, pero evité ponerme esa carga como propósito de año nuevo, y esperar a consolidarme en un nuevo trabajo. Y ese momento ha llegado. A día de hoy trabajo como Principal Engineer en Technosylva, una empresa que hace cosas que molan mucho, pero de la que os hablaré en otra ocasión. Así que creo que ahora, consolidado en mi nuevo trabajo, es buen momento para lanzar Principia Machina. Prometo no daros mucho la turra, y aseguro que los temas serán variados, entre ciencia y tecnología. Pero no voy a empezar hablando de lo que es la newsletter, ni creando expectativas. Ya veremos también la regularidad con la que publico. De momento, voy a empezar tratando un tema sobre el que me preguntaron varias veces en un par de procesos de selección: crear equipos autosuficientes.
Se considera un equipo autosuficiente a aquel que opera de forma independiente mientras que se mantiene alineado con los objetivos de la empresa. Es el sueño de todo mánager, y si además es hiperproductivo — de lo que hablaremos en otra ocasión — pues muchísimo mejor. Esto es más fácil decirlo que conseguirlo, pero los resultados pueden ser muy gratificantes.
Objetivos claros
En primer lugar, para que un equipo pueda establecer prioridades según los objetivos de la empresa, estos tienen que ser, además de conocidos, claros. Si el CEO o el responsable del departamento no comunica estos objetivos claramente — ya sea a través de OKRs o cualquier otro formalismo — es responsabilidad del mánager recabar esta información y ponerla a disposición del equipo.
Personal adecuado
No se trata de tener a los mejores ingenieros, sino a los adecuados. El equipo tiene que tener a personas a las que les guste el dominio en el que trabaja ese equipo. Hay que identificar los puntos débiles y la falta de conocimiento y, o bien invertir en formación (upskill) o contratar a gente con experiencia que traiga el conocimiento al equipo (hiring). Es importante contar con gente a la que delegar responsabilidades, que no necesariamente tienen que ser los mejores ingenieros.
Un ingeniero que disfruta resolviendo problemas de performance en sistemas distribuidos será más valioso en un equipo de plataforma que alguien brillante pero sin interés en ese campo.
Delegar responsabilidades
Una vez el CEO de una empresa en la que trabajaba me dijo:
Es preferible pedir perdón que pedir permiso.
Esa creo que es la clave en una relación de confianza. Estableciendo guardarraíles — medidas de protección de presupuesto, seguridad, etc. — puedes permitir al equipo tomar decisiones técnicas y de arquitectura. Si vas a dejar un equipo “desatendido”, es importante establecer métricas de rendimiento (e.g. DORA) y realizar regularmente retrospectivas para evaluarlas y mejorarlas.
Para saber que delegar, yo me baso en una variación de la matriz de Eisenhower:
Es urgente e importante/costoso, lo hago yo inmediatamente.
Es urgente y no importante/costoso, lo hago yo en otro momento o delego.
No es urgente, lo delego.
Establecer buenos procesos de ingeniería
Los equipos tienen que tener una metodología de trabajo bien definida — Scrum, Kanban, etc. — y un proceso para establecer prioridades, acorde a una serie de criterios — Valor de negocio, complejidad, dependencias. Hay que establecer también cómo es el Software Development Lifecycle (SDLC) y como automatizarlo con CI/CD. Con los sistemas en producción, también hay que decidir como se van a gestionar las incidencias y las rotaciones (on-call).
Una cosa de la que soy particularmente fan es del manual de ingeniería (Engineering Handbook), idea que adopté de GitLab pero que sólo apliqué al departamento de ingeniería. En el manual se recogen absolutamente todos los procesos operativos del departamento: cómo los mánagers realizan los 1-1s, como definir SLOs, cómo utilizar Semantic Versioning, etc. Es responsabilidad de todos mantener el manual actualizado. Si no sabes como se hace algo, mira el manual. Si se establece una nueva forma de trabajar, escríbela en el manual.
Invertir en herramientas
La primera herramienta de un ingeniero es su ordenador. Optimizar el gasto en equipamiento es un error muy común, porque el impacto en las cuentas es mínimo pero el impacto en el rendimiento y el estrés del desarrollador puede ser importante.
Un equipo es autosuficiente, y también más eficiente, cuando reduce al mínimo sus dependencias externas. Por ello es importante invertir en herramientas de observabilidad avanzadas, como Grafana Enterprise, Datadog, etc. Si disponen de buena información sobre el rendimiento de sus servicios en producción, podrán tomar mejores decisiones basadas en datos. Y además serán más eficientes en la resolución de problemas, tomando una actitud mucho más proactiva en la prevención.
Cultura
Last but not least, es necesario un entorno en el que los empleados quieran estar. La cultura no puede emerger únicamente de posters motivacionales o frases en Slack, sino de cómo se toman las decisiones en el día a día y de las relaciones interpersonales.
Seguridad psicológica: Los equipos autosuficientes funcionan porque los miembros se atreven a hablar, a cuestionar y a equivocarse sin miedo. Sin eso, la autonomía se convierte en parálisis.
Transparencia: Compartir la información de manera abierta — roadmaps, métricas, retrospectivas — evita silos y refuerza la alineación con los objetivos de la empresa.
Evitar el individualismo: No se trata de tener “héroes” que resuelven todo, sino de construir un espacio donde cualquiera pueda contribuir.
Responsabilidad compartida: La autonomía viene con el compromiso de hacerse cargo de las consecuencias, tanto de los éxitos como de los fallos.
Aprendizaje continuo: Un equipo autosuficiente no significa un equipo estático. Significa que sabe adaptarse, aprender de sus errores y evolucionar sus prácticas.
En mi experiencia, un equipo con procesos perfectos pero sin cultura sana acaba estancado. En cambio, un equipo con una cultura fuerte puede compensar muchas carencias técnicas mientras aprende. Al final, lo que más he valorado de un equipo es sentir que podía decir ‘no sé’ sin miedo a quedar mal.
¡Muchas gracias por leerme!