Antes de la conferencia Codemotion Madrid, donde abrirá el evento con su keynote «Playing Tetris with Cognitive Load», tuve el placer de hacerle algunas preguntas a Manuel Pais sobre su libro «Team Topologies: Organizing Business and Technology Teams for Fast Flow”«, sus actividades actuales y sus planes futuros:
Me gustaría presentarte ¿qué estás haciendo actualmente? ¿Cuál es tu trabajo a día de hoy?
Hoy en día, la gente me conoce como uno de los autores del libro ‘Team Topologies’. En la práctica, esto significa que voy de conferencia en conferencia, trabajo en formación y soy consultor para algunas empresas. También desarrollo productos relacionados con las ideas sobre equipos. Esto involucra múltiples aspectos y gestionar mi carga cognitiva no siempre es fácil, pero hay muchas cosas interesantes en marcha.
Esto se puede deducir de muchas entrevistas que he visto sobre ti en estos días. Una cosa que todos te preguntan en realidad es si puedes ser más específico sobre el término “topologie”:
El término “topologie” se utiliza comúnmente en ingeniería, particularmente en lo que respecta a la estructura de redes. La palabra deriva del griego y se refiere a cómo diferentes partes de un sistema están interrelacionadas u organizadas juntas. En el contexto de nuestro libro, significa pensar en cómo se relacionan entre sí diferentes equipos, si están conectados o no, y cómo tomar decisiones intencionales sobre estas conexiones. ¿Deberían estar más conectados? ¿Deberían colaborar más o ser más independientes? Uno de los puntos clave que discutimos es ser más específicos sobre el tipo de interacciones que deberían ocurrir entre los equipos, decidiendo cuándo es ventajoso colaborar para resolver un problema común y cuándo esa colaboración podría en realidad ocultar una falta de capacidad en algunos equipos.
Antes de comenzar a leer el libro, que encuentro muy interesante, algunos compañeros me han dicho que vuestro protocolo ha sido adoptado por Amazon como referencia para organizar los equipos internos. ¿Cómo te sientes respecto a este respaldo?
Es realmente interesante porque no hemos trabajado directamente con Amazon o AWS en esto, pero desde que el libro fue publicado hace casi cinco años, hemos visto un cambio en el tipo de solicitudes que recibimos. Inicialmente, eran principalmente de early adopters como pequeñas empresas en 2020 y 2021, que encontraban las ideas muy útiles y querían hacer cambios organizativos. Con el paso de los años, hemos empezado a ver interés también por parte de grandes empresas y sectores tradicionales como bancos y seguros, donde las nuevas ideas, especialmente sobre formas de organizarse y trabajar, tienden a ser adoptadas más lentamente. Es muy gratificante ver no solo pequeñas empresas, sino también grandes nombres como AWS aplicar los conceptos de las topologías de equipos. Han estado utilizando enfoques similares desde principios de los años 2000, donde enfatizan que los equipos deben poseer sus propios servicios y estar desacoplados, sabiendo cuándo colaborar y cuándo no colaborar en exceso.
Sabemos que la arquitectura y las estructuras de equipo deben diseñarse de manera que eviten que múltiples equipos estén involucrados cuando se desarrolla una nueva funcionalidad. Pero también sabemos que a veces esto ocurre, y está bien. ¿Qué sugerirías como la mejor manera de mantener sincronizadas las tareas en los backlogs de los equipos involucrados cuando hay dependencias?
Es una pregunta interesante. En primer lugar, es cierto que no siempre tendremos equipos que puedan trabajar completamente de forma autónoma en sus backlogs. Lo ideal es que los equipos sean más independientes y autosuficientes. Sin embargo, seguramente habrá situaciones que requieran que varios equipos se sincronicen para implementar un cambio. Si tenemos un buen equilibrio, digamos que el 80% del tiempo los equipos trabajan en sus backlogs y el 20% o menos necesitan colaborar con otros equipos, es mucho mejor que necesitar siempre de tres a cinco equipos para lograr algo. Cómo gestionar esto en la práctica depende un poco de la naturaleza de las tareas comunes a estos equipos. Si se trata de interfaces bien definidas, los equipos pueden colaborar inicialmente para definir estas interfaces, luego eventualmente utilizar servicios simulados para probar independientemente estas dependencias, controlando regularmente para asegurarse de que se mantengan sincronizadas a medida que las cosas evolucionan. Si hay mucha implicación, podría ser necesario una sincronización diaria entre todos los equipos para asegurarse de que las personas adecuadas estén colaborando y que las dependencias se manejen de manera efectiva.
¿Cuáles son los principales objetivos que las empresas buscan alcanzar al adoptar las estructuras y estrategias delineadas en las topologías de equipo? ¿Podemos definir algunos objetivos que perseguir inicialmente?
A menudo, las empresas buscan escalar; están creciendo, han tenido éxito con algunos productos o servicios y están empezando a ver dónde sus estructuras están colapsando. Esto podría funcionar en un contexto más pequeño o cuando un producto podría ser organizado y construido por uno o dos equipos. Luego se dan cuenta de que esto no funcionará a medida que crecen, y comienzan a identificar que les faltan habilidades, quizás necesitando diferentes servicios de plataforma, como se discute en el libro. A menudo se trata de crecimiento y escalabilidad de manera sensata porque lo que funciona hoy no escalará mañana. También se trata de lograr un flujo más rápido, ser capaz de responder más rápidamente a la competencia o llevar nuevos productos o valor al mercado más rápidamente. Dependiendo de la situación económica, como una congelación de contrataciones o inversiones reducidas, el enfoque podría desplazarse hacia la reducción de costos para que no ralentice a los equipos, manteniendo la efectividad incluso cuando no se está creciendo en tamaño.
Es evidente que provienes de un trasfondo de DevOps. Lo que me viene a la mente preguntarte es cómo se alinean los tipos de equipos identificados en el libro con los principios de DevOps.
Es una buena pregunta. Mi trasfondo está en ingeniería de software, y he estado profundamente involucrado con DevOps y Desarrollo Continuo. Los tipos de equipos de los que hablamos están estrechamente relacionados con los principios de DevOps. Por ejemplo, uno de los tres principios de DevOps es lograr un flujo más rápido, lo que significa una entrega más rápida de valor a los clientes. El primer tipo de equipo del que hablamos son los equipos streamline, que se centran en este flujo más rápido. En DevOps, enfatizamos ciclos de retroalimentación más cortos y mayor autonomía, que los equipos streamline ejemplifican. Manejan el producto desde el principio hasta el final, desde la recopilación de los requisitos de los clientes hasta la entrega y pruebas del producto en producción, alineándose con el primer principio de DevOps: mejorar el flujo. El segundo principio trata sobre feedback rápido, y estos equipos, gracias a su estructura, pueden obtener feedback rápidamente porque no dependen de otros equipos. El tercer principio es el aprendizaje continuo, que es fundamental para los equipos que gestionan la propiedad de extremo a extremo, requiriendo un amplio conjunto de habilidades y conocimientos.
Profundicemos en la dinámica de los individuos en los equipos. He leído una cita que decía que los individuos dentro de estos equipos crecen para actuar como un equipo unido en lugar de solo como un grupo de personas. ¿Puedes sugerir las mejores prácticas para seleccionar individuos que funcionen bien en un equipo?
Los tipos de equipos que hemos definido ayudan a guiar la selección de individuos no solo en función de las necesidades operativas sino también de las motivaciones e inclinaciones personales. Por ejemplo, alguien con habilidades específicas que ama compartir conocimientos podría adaptarse bien a un equipo abilitante, mientras que alguien que prospera enfrentando desafíos técnicos podría ser más adecuado para un equipo de plataforma. Es importante que los miembros del equipo tengan una combinación de habilidades requeridas para sus roles. Sin embargo, en muchas organizaciones, es difícil para los individuos cambiar a roles donde se sienten más motivados. A menudo, las personas son reclutadas para equipos específicos y luego descubren posteriormente que no es la mejor colocación. Hay casos en los que los miembros de los equipos abilitantes han pasado a equipos de plataforma porque preferían desarrollar soluciones directamente en lugar de enseñar o mentorear. Idealmente, las organizaciones deberían facilitar tales transiciones para garantizar que los individuos estén en roles que se adapten mejor a sus habilidades e intereses.
¿Crees que este enfoque debería ser adoptado de arriba hacia abajo en un entorno que apoya el desarrollo profesional, o puede comenzar de abajo hacia arriba, partiendo de los individuos dentro de la organización?
Es interesante porque muchos nuevos enfoques organizativos, incluidos los de ingeniería, a menudo requieren una combinación de estrategias de abajo hacia arriba y de arriba hacia abajo para consolidarse. Cuando estábamos escribiendo «Team Topologies», inicialmente pensamos que interesaría principalmente a la alta dirección y a quienes deciden sobre las estructuras de equipo. Sin embargo, nos sorprendió descubrir que incluso los coaches ágiles, arquitectos e incluso contribuyentes individuales estaban leyendo el libro. Hay aspectos de nuestro enfoque que pueden ser implementados de abajo hacia arriba. Por ejemplo, los equipos pueden ser más conscientes de cómo interactúan con otros equipos y cómo definen y comunican sus APIs de equipo para clarificar sus modos de interacción y prácticas preferidas. Si estas prácticas son adoptadas a nivel de equipo y demuestran ser beneficiosas, pueden influir en cambios organizativos más amplios. Idealmente, se utilizan ambos enfoques: las personas dentro de la organización adoptan y respaldan las prácticas, y el liderazgo reconoce su valor y apoya una implementación más amplia.
Muy interesante. Por último, la pregunta obligada sobre inteligencia artificial. ¿Influye en las topologías de equipo y, de ser así, cuáles son los principales efectos?
Sí, la inteligencia artificial, especialmente la IA generativa, está afectando notablemente las topologías de equipo dentro de los equipos orientados a la tecnología. Es importante que las organizaciones estén preparadas para integrar herramientas de IA. No se trata solo de adoptar nuevas herramientas como Copilot; es importante comprender cómo estas herramientas están cambiando nuestras formas de trabajar e influyendo en nuestra carga cognitiva. Organizativamente, debemos pensar en cómo utilizar la IA de manera efectiva en todos los frentes, lo que podría incluir la creación de equipos habilitantes para difundir buenas prácticas y abordar cuestiones éticas y de seguridad asociadas con el uso de IA. En última instancia, el uso efectivo de la IA en las organizaciones debería verse como un fortalecimiento de las capacidades, no solo a nivel de equipo individual, sino en toda la organización.
Mi última pregunta: en YouTube vi un video en el que hablabas sobre topologías en seguridad. ¿Es tu próximo tema? ¿Estás planeando desarrollar algo en estas líneas?
No, no estamos escribiendo un libro específicamente sobre eso. El éxito de «team topologies» es bastante fascinante porque ha inspirado a las personas a expandir algunas de las ideas en dominios específicos, como la seguridad, por ejemplo. Creo que te estás refiriendo a una sesión que tuve con Mario Platt, que es un experto en seguridad. Estaba explicando diferentes topologías de seguridad que se centran en una mentalidad habilitadora que ayuda a los equipos a comprender lo suficientemente bien la seguridad como para integrar prácticas DevSecOps en lo que yo llamaría equipos ágiles.
La seguridad es un dominio amplio, y hay muchos aspectos a considerar. Por ejemplo, Eduardo da Silva ha realizado un trabajo realmente interesante sobre cómo los equipos habilitantes pueden ayudar a construir capacidades de ciencia de datos. Nuestro trabajo actual no trata sobre escribir específicamente sobre estos temas, sino más bien sobre amplificar el gran trabajo que están haciendo estos expertos y otros.
Mi enfoque, junto con Matthew, está en cómo estas ideas sobre flujo rápido, topologías de equipo y modelos pueden aplicarse más ampliamente, no solo en ingeniería. Por ejemplo, hemos hablado con organizaciones en varios sectores, como un estudio legal que no desarrolla software y organizaciones de atención médica. Estas discusiones giran en torno a cómo acelerar los procesos de trabajo mejorando los sistemas en los que operamos, garantizando una retroalimentación rápida y abordando aspectos críticos como la seguridad del paciente en la atención médica.
Hay ejemplos interesantes, especialmente en el Reino Unido, de aplicación de estas ideas durante la pandemia, como el desarrollo de sistemas para la gestión de vacunas. Entonces, aunque no preveamos publicar un libro este año o el próximo, estamos considerando recopilar estas experiencias en un libro dentro de unos años, ofreciendo una perspectiva más amplia y coherente.
Muchas gracias por tu tiempo, espero verte en tu ponencia en Codemotion Madrid.
Ha sido un placer, ¡espero verte en la Conferencia Codemotion Madrid!
