Webinar – Data, Explored #7 – New Perspectives on Team Topologies

En primer lugar, una cálida bienvenida, Manuel Pais, a Data Explored. Gracias. Gracias.

Es un honor tenerte aquí. Para los oyentes y los espectadores, quiero decirte que eres un conferenciante con mucha experiencia. Eres el coinventor del concepto de «Team Topologies», que es tanto un libro como una academia.

Así que, obviamente, también eres coautor de «The Platform Manifesto», que escribiste, y además eres líder de pensamiento de Fast Flow. Y hablas portugués. Ya veo... Sí, pero no en este seminario en línea.

No. Quería decir algo en portugués, pero no puedo. Lo siento.

Pero... No pasa nada... Es un verdadero placer tenerte aquí, Manuel Pais. He disfrutado mucho con tu trabajo y te he seguido muy de cerca.

Hemos organizado esta llamada para hablar de la segunda edición de tu libro, «Team Topologies». Sé que tengo puesto el auricular, así que no estoy seguro de poder... Pero tengo tanto la primera como la segunda edición... Genial... porque leí la...

Sí. Ahora tengo la costumbre de no tirar las primeras ediciones de los libros que compro en segunda edición, porque a veces tomo notas y, si no puedo volver atrás y encontrarlas, me siento un poco perdido. Sé que soy un friki, pero bueno, así soy yo.

Pero he leído el libro que has escrito junto con Matthew Skelton. Así que, básicamente, tengo muchas preguntas, y además tuvimos tiempo de repasar algunas cosas antes de empezar la retransmisión en directo, y quizá tengamos tiempo de hablar de eso durante esta llamada. Tenemos aproximadamente una hora.

Y si alguien quiere hacer alguna pregunta, por favor, utilice la sección de preguntas y respuestas y no el chat. Pero para este seminario en línea, sugiero que empecemos hablando de algunos aspectos relacionados con el libro, no de lo que hay en el libro, sino de lo que lo rodea. Porque, obviamente, todavía es un poco pronto para hablar de la segunda edición en cuanto a cómo se ha elaborado.

Pero la primera edición, porque acaba de salir, ¿no? Pero la primera edición... Sí, en septiembre del año pasado. Vaya, ya en septiembre.

Sí. El tiempo pasa volando. ¿De verdad ya es septiembre del año pasado?

Sí. Vaya. Sí.

Ahí lo tienes. Pero lo que quiero saber es que la primera edición tiene varios miles de reseñas en Amazon, así que no me des una cifra. No creo que debas hacerlo, pero a ese libro le ha ido bien, ¿verdad?

¿Y qué se siente al escribir un libro que está teniendo tanto éxito? Bueno, se siente muy bien. Pero también quería daros las gracias por invitarme.

Por supuesto, también admiro tu trabajo como autor, y la verdad es que lo has hecho muy bien. Además, he disfrutado mucho de nuestras conversaciones sobre diferentes temas. El libro, «Team Topologies», salió a la venta en 2019, en su primera edición.

Ha tenido mucho éxito. Creo que, obviamente —y ya lo comentábamos un poco antes de empezar—, para mí, el libro, y también para Matthew, no fue algo que dijéramos: «Vaya, tenemos una idea genial. Escribamos sobre esto». Fue algo que se fue consolidando a lo largo de muchos años de mi experiencia y de la suya, y creo que hubo múltiples factores que contribuyeron a su éxito.

Creo que las últimas cifras que recuerdo eran algo así como 200 000 ejemplares en los primeros cinco años, más o menos. Así que está bastante bien.

Vaya. Creo que fue una combinación de factores; nuestras experiencias, las mías y las de Matthew, encajaron a la perfección. Escribimos el libro en un momento en el que muchas empresas —y esto lo oíamos una y otra vez— decían: «Esto es justo lo que necesitábamos», porque sabíamos que teníamos algunos problemas organizativos, pero no contábamos con una forma estructurada de abordarlos.

Además, se basó en la experiencia que Matthew y yo adquirimos durante varios años trabajando como consultores en el ámbito de DevOps y la entrega continua. Si pensamos en los principios que subyacen a todo ello, están muy en línea con los principios de «Team Topologies», salvo que nos centramos más en el aspecto organizativo que en el técnico y en las prácticas. Y creo que era el momento adecuado para escribir ese libro.

Ya habíamos trabajado anteriormente en lo que llamamos «DevOps Topologies». El proyecto lo inició Matthew y luego yo ayudé a desarrollarlo; se trataba de una página web. Sigue disponible en línea, por si alguien quiere echarle un vistazo a «DevOps Topologies».

Y entonces empezamos a darnos cuenta de que los patrones van más allá de DevOps, que era algo muy importante en aquel momento. Y lo que es realmente genial... Ahora me estoy desviando un poco del tema, pero siempre puedes interrumpirme. No.

Pero lo que realmente mola ver ahora es que, obviamente, todo el mundo habla de la IA, ¿verdad? Cuando pensamos en los patrones que describimos en Team Topologies y en los principios —que es una de las cosas que intentamos reforzar en la segunda edición—, hay un nuevo prólogo que profundiza más en cuáles eran los principios que sustentaban Team Topologies en la primera edición, porque en realidad no escribimos demasiado sobre eso. Nos centramos más directamente en los patrones y los objetivos.

Pero hay una serie de principios, y cuando se analiza la IA desde una perspectiva organizativa, diría que casi todo lo que escribimos en la primera edición sigue siendo válido en lo que respecta a la gestión de la carga cognitiva, a cómo organizarse para lograr un flujo ágil cuando se da más autonomía a los equipos, y todas esas cuestiones. Por supuesto, cuando se añade la IA, eso puede acelerar ciertas cosas, pero también puede ralentizar otras si no se está organizado de una manera centrada en aportar valor a los clientes. Pero bueno, me estaba desviando un poco del tema ahí.

No, en absoluto.

Y, de hecho, dentro de un rato podremos profundizar en eso. Pero antes de hacerlo, hay muchas cosas en el libro que me gustan y que resultan sorprendentes. Supongo que mucha gente del mundo tecnológico habrá oído hablar de la Ley de Conway, porque refleja con gran precisión el efecto que los sistemas informáticos tienen en las organizaciones.

Así que resulta muy interesante hablar de la Ley de Conway, de sus consecuencias, de cómo evitarla y demás. Tú también mencionas la Ley de Conway. Pero, además, citas muchos otros libros y muchas otras perspectivas.

Y uno de los libros que mencionas es ese libro que te inspiró, titulado «Mejorar el rendimiento: cómo gestionar los espacios en blanco del organigrama». Sí. Y esa es una observación realmente interesante. ¿Qué potencial ves, o mejor dicho, qué potencial viste —y supongo que sigues viendo, obviamente— en los espacios en blanco del organigrama?

Y para poner un poco en contexto a quienes nos escuchan, es evidente que un organigrama tiene recuadros y flechas, y contiene los nombres de las unidades de negocio y demás. Pero justo al lado de todo eso, como es lógico, está el espacio en blanco. Sin embargo, lo que usted dice es que hay algo en ese espacio en blanco, que hay un potencial en ese espacio en blanco que debe desarrollarse para que las organizaciones sean eficaces.

¿Y qué viste en el espacio en blanco, Manuel? Sí. El concepto clave de ese libro era precisamente esa idea del espacio en blanco.

Porque pone de manifiesto muchas de las, digamos, disfunciones de las organizaciones; es decir, cuando miramos el organigrama, normalmente tiene sentido. Nos organizamos así, con las distintas áreas y demás. Pero luego el «espacio en blanco» es todo aquello que no aparece representado allí, lo que ocurre en el día a día.

Así que es casi como si se tratara de esas cosas que no se declaran ni se entienden de forma intencionada, y que a menudo tienen que ver con las interfaces entre equipos, entre departamentos. Porque entonces, si miras un organigrama, como decías, todo son cuadros y flechas, y ves cómo estáis organizados. Si superpones cómo se hace realmente el trabajo, ahí es donde el espacio en blanco se vuelve, cómo decirlo, más visible, y te das cuenta de que hay muchas cosas en las que no se ha pensado claramente de forma intencionada, y ahí es donde empiezas a verlo.

Y esto es interesante: un ejercicio muy sencillo que la gente puede hacer en su propia organización es pensar en algún trabajo que haya realizado, tal vez una nueva función o algo de valor, y empezar a trazar una línea a través del organigrama para ver qué departamentos y equipos tuvieron que participar, y a menudo uno se encuentra con un gran lío. Y es interesante, incluso en la segunda edición de Team Topologies hay un caso práctico. De hecho, hay 10 nuevos casos prácticos en la segunda edición, porque uno de los objetivos de la segunda edición era contar con casos de empresas que hubieran empezado a aplicar Team Topologies.

En la primera edición, los casos se centraban más en patrones concretos. Pero ahora hablamos de empresas, y de grandes empresas que realmente han adoptado esas ideas y las han puesto en práctica. Por ejemplo, hay una empresa llamada Telenet en Bélgica.

Son uno de los principales operadores de telecomunicaciones. Y en el caso práctico, se dieron cuenta de que el punto de partida era que contaban con todas esas tribus. Así que, si nos fijamos únicamente en la organización por tribus, tiene sentido sobre el papel.

Vale, hay un equipo para la atención al cliente, otro para esto y otro para aquello. Y luego trazaron las líneas, como decía, para definir cuándo se lleva a cabo realmente el trabajo y cuáles son las dependencias.

Y, básicamente, son líneas por todas partes. Mm-hmm. Y ahí es donde el espacio en blanco que había antes se convierte, bueno, ahora quizá podamos llamarlo «espacio oscuro».

No lo sé. Simplemente queda claro que había muchas cosas que no funcionaban bien. Y, por cierto, ese caso práctico es muy interesante, porque aplicaron algunos de los conceptos y los tipos de equipos de los que hablamos en «Team Topologies» a nivel de tribu.

Así que dicen que esta tribu se centra en el cliente final, que esta tribu es una tribu de plataforma que proporciona capacidades internas, etcétera. Pero sí, desde ese punto de vista, el «espacio en blanco» son aquellas cosas que no están definidas de forma clara e intencionada y que acaban convirtiéndose en grandes obstáculos a la hora de aportar valor a nuestros clientes. Sí.

Para mí, el espacio en blanco es a la vez un laberinto oculto y, al mismo tiempo, la forma en que realmente se lleva a cabo el trabajo. Sí. Así que es ambas cosas.

Es precisamente el ajetreo del día a día laboral lo que no queda realmente reflejado en esos gráficos tan formales. Y volveremos sobre los casos prácticos y los cambios que hicisteis en la segunda edición, porque realmente merece mucho la pena leerlos. Así que sin duda volveremos sobre ello.

Pero supongo, y sé que ya has hecho esto un montón de veces, así que, por favor, no te caigas de la silla de lo aburrido que te resulte, Manuel. Es como... Pero, muy brevemente, ¿qué equipos sugieres que adopten las empresas? Sí.

Claro. No hay problema. Es como un grupo que toca sus grandes éxitos, ¿no?

Todas las noches. Sí. No, pero en realidad, como decía, cuando escribimos la primera edición, creo que esa es una de las principales diferencias con respecto a la segunda edición.

La primera edición se parecía mucho a lo que habíamos visto en esos patrones y en este trabajo, y, como ya he dicho, habíamos consolidado muchos de esos patrones e ideas a partir de nuestro trabajo, y luego quisimos plasmarlos en el libro. Así que solía decir algo así como: «Vale, este es este tipo de equipo y aquel es aquel tipo de equipo». Hoy en día, me gusta —y contigo— empezar por el porqué.

Así pues, Team Topologies se centra en lograr un flujo rápido de valor hacia el cliente. Por eso es importante tener presente que no se trata simplemente de decir: «Vamos a ir rápido y a convertirnos en una máquina de producir cosas». Su valor solo se materializa cuando hay alguien que consume lo que ofreces, y eso le ayuda a él y a tu organización. Ahí es donde se genera el valor.

No se trata solo de ofrecer funciones, ni de «basura de IA» ni nada por el estilo. Así que, si es eso lo que queremos, entonces, en cierta medida, los tipos de equipos de los que hablamos en «Team Topologies» están pensados como imanes, en el sentido de que es eso lo que deberíamos aspirar a conseguir. Y el primer tipo es lo que llamamos equipos alineados con el flujo.

Es algo parecido a los equipos de producto multifuncionales. La razón por la que queríamos diferenciar los «streams» es que los productos suelen ser muy complejos, por lo que no es posible que un solo equipo se encargue de todo un producto. Por eso tenemos que pensar, dentro de cada producto, cuáles son los diferentes «streams».

Y las vías de desarrollo pueden adaptarse a las distintas perfiles de usuario que existen para un mismo producto. Así que quizá necesitemos equipos diferentes centrados en los perfiles con más experiencia, en los que tienen menos, o en cualquier otra diferencia que pueda haber. O bien, obviamente, tenemos distintos recorridos de usuario dentro del producto, y quizá eso sea lo que justifique la existencia de vías de desarrollo diferentes.

O, a veces, se trata de un conjunto de funcionalidades o características que son bastante independientes entre sí, como podría ser el caso de tus flujos. A menudo es una combinación de estos diferentes factores. Y, de hecho, eso se relaciona con lo que decías antes sobre la Ley de Conway, donde, desde el punto de vista de la arquitectura técnica, obviamente hemos pasado de pensar que los monolitos son malos, que son aplicaciones grandes y que es difícil cambiarlas y hacerlas evolucionar.

Y luego llegaron los microservicios y pensamos: «Vale, si contamos con toda esta modularidad y estos pequeños servicios, podremos desarrollarlos más rápido». Pero, en realidad, nos faltaba algo en el medio, que podría llamarse de cualquier manera: macroservicios o cualquier tipo de servicio que se adapte bien a un equipo. Porque probablemente no querrás tener cientos de pequeños servicios de los que tenga que encargarse el mismo equipo.

Así que ahí es donde, idealmente, estos equipos alineados con los flujos deberían ser responsables de un servicio o de una parte de un producto que sea en gran medida independiente del resto, de modo que pueda evolucionar por sí solo y aportar valor a los clientes. Por lo tanto, no se trata solo de un componente técnico, sino de algo que tiene un valor claro, y sabemos quiénes son sus usuarios y cuáles son sus necesidades. Ahora bien, la dificultad con este tipo de equipos es que se espera que un equipo bastante pequeño tenga muchas competencias y habilidades diferentes.

Y también hay mucho que hacer en cuanto a comprender a los clientes, llevar a cabo el proceso de descubrimiento y, a continuación, plasmarlo en software real o en lo que necesitamos desarrollar, para luego entregarlo a los clientes y analizar si se está utilizando, si está mejorando las métricas empresariales y todo eso. Lo ideal es que todo eso entre dentro del ámbito de competencia del equipo alineado con el flujo. Y eso es mucho con lo que lidiar, y esa es la razón principal por la que incluimos otros tipos de equipos.

Así pues, hay otros tres tipos de equipos, los llamados equipos de apoyo, que suelen ser expertos en algún ámbito. Y su función no es, por así decirlo, realizar el trabajo especializado. Consiste en ayudar a los equipos a adquirir los conocimientos necesarios para que puedan llevar a cabo el trabajo.

Y eso supone un cambio muy importante con respecto a la visión tradicional, según la cual hay una especie de «expertos» a los que se recurre. Son las únicas personas que saben cómo hacer X. Si esas personas trabajan de forma facilitadora, estarán aplicando el viejo dicho: «No le des a la gente el pescado, enséñales a pescar para que puedan ser más autosuficientes». Mm-hmm.

Eso se refiere más bien al ámbito de las competencias. Y luego están los equipos de plataforma, que aclaramos un poco en la segunda edición. Pero, en esencia, se trata de equipos que ofrecen productos internos, si se quiere considerarlos como productos destinados a los equipos internos para que estos tengan menos de qué preocuparse.

Tienen menos de lo que llamamos «carga cognitiva», porque contamos con servicios internos que nos pueden ayudar. A menudo se empieza por muchos de los aspectos técnicos, como las implementaciones, la supervisión o la infraestructura. Todo eso se puede hacer de forma automatizada —idealmente a través de la plataforma— y fácil de usar.

De este modo, se eliminan muchas preocupaciones del equipo alineado con el flujo, de modo que puedan centrarse en las necesidades del cliente. Y luego teníamos equipos de subsistemas complicados, sobre los que debatimos mucho, ya que no está claro si son realmente necesarios; pero hay situaciones puntuales en las que se tiene un algoritmo muy complejo, algún subsistema o incluso algún servicio que realiza un procesamiento complejo o que tiene unas necesidades de procesamiento o de computación muy exigentes. Y a veces se necesita un equipo dedicado a ese servicio o subsistema porque, si se le pide al equipo alineado con el flujo que lo haga, simplemente va a saturar su capacidad cognitiva.

Así pues, esos equipos de subsistemas complejos pueden considerarse casi como una especie de miniplataforma. Se trata solo de un tipo de subsistema o servicio, pero debe ofrecerse de manera que resulte fácil de utilizar para los equipos alineados con los flujos. Sí.

Gracias. Así que esos son los cuatro... Gracias... tipos.

Sí. Gracias. Y gracias por dedicarme tu tiempo.

Debe de ser la enésima vez... No sé cuántos millones de veces lo has dicho, pero... He perdido la cuenta. Sí. Claro.

Pero teníamos que dejar esto claro porque, básicamente, los equipos que propones funcionan según topologías, ¿no? Esa es la idea de las topologías de equipo. Se trata de que estos equipos... Sí...

Trabajan en entornos concretos, en empresas concretas para hacer cosas concretas, ¿no? Sí. Y van evolucionando.

O deberían evolucionar de forma bastante continua. Así que la topología es, por tanto, una combinación de diferentes tipos de equipos, así como de sus interacciones, ¿no? Si lo consideramos como un sistema, en el que, de nuevo, idealmente, si solo tuviéramos equipos alineados con el flujo, con todas las competencias y una carga cognitiva razonable para todos ellos, eso sería todo lo que necesitaríamos.

Basta con que los equipos, organizados en flujos, trabajen en paralelo para aportar valor a los clientes. Pero sabemos que eso no es muy realista. Así que la topología se asemeja bastante a esta idea de un «equipo de equipos» que colaboran de forma eficaz para, de este modo, aportar valor a los clientes.

Pero, con el tiempo, debería ir evolucionando. En función de los retos a los que nos enfrentamos hoy en día. Si pensamos en la situación actual, quizá haya algunas carencias en los equipos a la hora de adoptar la IA o de comprender cómo integrarla en nuestros flujos de trabajo y en nuestros productos de una manera ética.

Y hay muchas cuestiones en las que quizá necesitemos la ayuda de algunos expertos o de un equipo de apoyo que ayude a los equipos alineados con los flujos a resolver estas cuestiones. Quizá necesitemos herramientas de plataforma que faciliten el uso de algunos de estos nuevos enfoques. Así que esos podrían ser los retos actuales.

Pero quizá dentro de uno, dos o tres años, todo esto esté más o menos consolidado en la organización. Sabremos más o menos qué utilizar, y los equipos tendrán los conocimientos suficientes, así que quizá ya no necesitemos los mismos equipos de apoyo, o quizá surjan nuevos servicios de plataforma, ya que lo que antes era más experimental ahora se ha consolidado. Esta es una buena forma de hacerlo, y podríamos ofrecerlo como un servicio de plataforma.

Por eso es fundamental considerar las topologías como algo que no es estático. No se trata de un modelo operativo estático, por así decirlo.

Es lo que funciona hoy en día para hacer frente a los retos a los que nos enfrentamos, que van a ir evolucionando en los próximos meses y años. Sí, y me gusta esa flexibilidad. Es una estructura organizativa capaz de adaptarse, cambiar y reorientarse, y cualquiera que haya trabajado en el sector tecnológico sabe que una organización debe ser capaz de hacerlo.

Sí. Si no, acabas teniendo estructuras muy, muy pesadas, con equipos de gran complejidad y baja... mm... productividad, básicamente.

Supongo que todos hemos pasado por eso en algún momento de nuestra carrera. Y también es interesante: me doy cuenta de que muchas empresas invierten mucho, no solo en herramientas, sino sobre todo en conocimientos especializados y en contar con buenas prácticas. Obviamente, ahora estamos hablando de IA, pero eso fue antes de DevOps y CI/CD; si hablamos de aspectos más técnicos, obviamente estás en el campo de los datos, cosas como la malla de datos y todo eso.

Por supuesto, suelen necesitar conocimientos especializados y herramientas, y en eso invierten mucho, pero no invierten en la parte que lo hace posible. Así que es como si tuviéramos cosas realmente buenas que podemos usar, pero la gente no las está aprovechando porque los equipos alineados con el flujo o los equipos de producto están ocupados con su día a día, y tienen mucha presión para entregar, y nadie ha ido a ayudarles a averiguar cómo hacer bien estas cosas, ¿verdad? A menudo pueden adoptar algunas cosas porque hay cierta presión para hacerlo, ya sabes, tenemos que aplicar DevOps o lo que sea.

Pero a menudo acaban haciéndolo de forma desorganizada. Por eso, la parte de facilitar el proceso es realmente interesante y, al menos para mí, es uno de los aspectos de Team Topologies de los que me siento más orgulloso. Es algo que resulta desconocido para muchas organizaciones, y cuando ven cómo se pone en práctica, se dan cuenta del impacto que tiene; pero es tan sencillo como enseñar a la gente a utilizar estas excelentes herramientas y prácticas.

No basta con dárselas y esperar que aprendan por arte de magia, ¿verdad?

Porque a menudo no hay espacio suficiente para aprender y poner realmente en práctica lo aprendido. No, supongo que puedo admitir que soy un friki. Pero ver cómo la tecnología empresarial funciona de verdad es un auténtico placer para mí, y lo he experimentado muchas veces en primera persona.

Es evidente que creo que la tasa de fracaso de la tecnología empresarial es tremendamente alta. Cuando trabajaba en otros puestos, lo veía de vez en cuando, ¿no? Esos proyectos de TI fallidos... Sí...

o esos equipos que se contrataban, y normalmente, se trataba de científicos de datos hace unos 10 años, ¿verdad? Y cobraban sueldos enormes, y en realidad no hacían nada, o muy poco, salvo ser genios matemáticos, y qué decepción, ¿no? Pero, en fin, y eso realmente tiene que ver con la flexibilidad y la usabilidad de los conjuntos de habilidades técnicas, las personas y la tecnología, y supongo que esta «Team Topology» es como la dimensión organizativa de estas descentralizaciones tecnológicas que hemos visto, la malla de datos, los microservicios.

¿Hasta qué punto están relacionados estos temas, y cómo sueles interpretar esta conexión con los movimientos de descentralización tecnológica? Sí... Sí, yo diría que, si lo miras desde una perspectiva general, en realidad es justo lo que mencionaste antes.

La Ley de Conway aborda el impacto que tienen nuestra forma de organizarnos y nuestra capacidad de comunicación, así como las interfaces entre equipos y el tipo de sistemas que somos capaces de crear. Pero hay una tercera dimensión en todo esto, que es, por así decirlo, la arquitectura empresarial propiamente dicha. Así pues, cada empresa utiliza un vocabulario propio para describir cómo está organizada su actividad.

Me gusta hablar de flujos de valor. Si las empresas han utilizado enfoques como el diseño basado en dominios, suelen hablar de dominios de negocio y subdominios. Pero, al fin y al cabo, estamos hablando de lo mismo: de comprender la arquitectura de tu negocio.

¿Qué valor aportáis a qué clientes y cómo está organizado? ¿Qué hay en las diferentes corrientes de valor o ámbitos, etcétera? Y que esa arquitectura empresarial esté alineada con vuestra arquitectura organizativa, con vuestra estructura y organigrama, pero también con los canales de comunicación y todo eso.

Y si eso encaja con tu arquitectura técnica, entonces tienes una gran ventaja, ya que todo está en sintonía. No hay conflictos entre sí. Así que creo que lo que ha pasado, no sé si es un poco, cómo decirlo, arrogante por mi parte decirlo, pero creo que hasta Team Topologies, había una especie de separación entre, vale, está la arquitectura técnica, y ahí es donde entran en juego cosas como los microservicios y la malla de datos, hasta cierto punto.

Y esas cosas son... esos patrones, esas ideas son buenas y útiles, pero no estaban conectadas con el resto, con el aspecto organizativo. Quizá no estábamos viendo tanto el impacto de si simplemente adoptamos microservicios; como decía antes, vale, si acabas teniendo cientos o miles de microservicios, tienes una carga mucho mayor a la hora de gestionar todos esos servicios. Y a menudo las empresas empiezan a darse cuenta de que esto en realidad no nos ayuda a ir más rápido.

Tenemos más cargas de trabajo que antes porque cuentan con todos estos pequeños servicios, y a menudo no se dividían ni se segmentaban en función de las necesidades de los clientes. Nos basamos más en criterios funcionales. Y creo que ahí radicaba la discrepancia: adoptábamos estas buenas prácticas técnicas, pero luego no tenían el impacto que esperábamos en el negocio ni la capacidad de aportar valor rápidamente.

Y por eso creo que, en algún momento, intentamos introducir también las topologías de equipo para que los equipos reflexionen —o cuando se piensa en la arquitectura técnica— sobre qué tiene sentido para un equipo de, por lo general, hasta ocho o nueve personas. Qué tiene sentido, como servicio o como parte de un producto, para que un equipo pueda gestionarlo y aportar valor de forma mayoritariamente independiente en ese servicio o flujo específico. ¿No es así?

Es como atar cabos, por así decirlo. Sí. Supongo que puedo ser sincero al respecto.

No sé si debería darme vergüenza o no, pero sabía que *Team Topologies* era un libro importante antes de leerlo. Lo que pasa es que no sabía muy bien por qué. Y me llevó...

Leía y leía, y al principio seguía sin entender por qué era importante. Y entonces caí en la cuenta, ¿no? Justo lo que tú mencionas me hizo darme cuenta de que, vale, estamos acostumbrados a pensar en las tecnologías como algo que hay que desmontar.

Hay que desmantelar las arquitecturas de datos. Hay que desmantelar los grandes sistemas ERP. Sea lo que sea, hay que desmontar ese monolito para liberar todo el potencial de lo que sea que estés gestionando.

Y entonces me di cuenta de que, bueno, este libro trata sobre el hecho de que tú también puedes hacer lo mismo, o de que debes hacer lo mismo por tu organización. Eso también es un monolito, y tú también puedes desmontarlo. Y de eso trata este libro.

Y entonces lo entendí. Al menos eso creo, pero dímelo tú. En fin.

Sí, creo que sí. Bueno, gracias. Lo tenemos grabado.

Gracias. Si relacionas eso con lo que me preguntabas antes sobre el motivo del éxito del libro, creo que, por un lado, mucha gente dijo: «Me sentí identificado», como cuando hablamos de los puntos débiles y de lo que acabas de decir: si solo miramos en una dimensión, entonces nos esforzamos por mejorar, digamos, la arquitectura técnica y nuestra forma de trabajar, y no vemos el impacto en el otro lado. Así que la gente se sintió muy identificada con cómo describíamos los problemas.

Y además, algunas personas también dijeron, y yo estoy de acuerdo, que las ideas que aportamos en cuanto a soluciones, por así decirlo, o los patrones, se basan en gran medida en lo que ya se ha hecho en el pasado: el movimiento DevOps, Agile hasta cierto punto, y el pensamiento sistémico, que también es muy importante. Así que algunos dirían: «Bueno, no hay nada especialmente novedoso en Team Topologies», pero lo novedoso era cómo reunía todas esas cosas, dándoles un vocabulario. Y, como dije antes, creo que la parte habilitadora es aquella en la que quizá mucha gente no había pensado para hacerla más intencionada.

Pero, por supuesto, gran parte de todo esto se basa en lo que ya sabíamos del pasado, incluso ideas como la «plataforma como producto». Sin embargo, se trataba de ponerlo todo en perspectiva. Creo que, al fin y al cabo, eso es lo que hizo «Team Topologies».

Y quizá por eso dices que te llevó un tiempo entender por qué es importante: porque, creo, une los puntos de muchas cosas que hemos sentido, que hemos sabido. Aquí hay algo que no cuadra. ¿Por qué no vemos resultados diferentes?

Así que, en mi opinión, el valor de «Team Topologies» radica en que, en un libro bastante breve, reúne todos estos conceptos y permite comprender el aspecto organizativo, además de estar muy en consonancia con los principios técnicos y las ideas que subyacen a DevOps y la entrega continua.

Así que también tenía sentido para mucha gente del ámbito técnico. Por supuesto. Yo también me sentí identificado con ese libro, al igual que muchos otros lectores.

Profundicemos ahora un poco más en la segunda edición. Hay algunos cambios, y ya lo has mencionado un poco, pero analicémoslo con más detalle. Sí.

Quiero dejar para el final los casos prácticos porque hay muchísimos, son muy interesantes y muy variados. ¿Verdad? Así que quiero dejar ese tema para más adelante.

Lo primero de lo que creo que deberíamos hablar, básicamente, es algo que me toca muy de cerca porque le he dedicado la mayor parte de mi carrera. Así que déjenme ponerles un poco en antecedentes. Esta es una larga introducción a una pregunta breve.

Les pido un poco de paciencia. He trabajado la mayor parte de mi carrera en grandes empresas, tanto como empleado interno como consultor externo, asesorando a muchas personas, y todo eso despegó básicamente cuando me convertí en autor de libros sobre tecnología y lo que escribí tuvo buena acogida. Así que creé mi propia empresa de consultoría, además de mi trabajo interno.

Lo que hice y con lo que me topé muy a menudo fueron esas múltiples tecnologías idénticas o tecnologías que hacían más o menos lo mismo, aunque quizá no exactamente lo mismo. En gran medida debido al estudio que realicé, o más bien a la dirección que tomé, sobre todo en el ámbito de los metadatos. Esas tecnologías que considero capaces de conectarse en una red, una «metared», como yo la llamé. Pero basta ya de hablar de mí.

Lo que me parece tan interesante es que cambiaste un equipo concreto en la configuración de la topología de equipos, que es el equipo de la plataforma. Y se basa en... Supongo que tu coautor, Matthew, dijo que, de hecho, lo discutisteis durante la redacción de la primera edición, pero... Sí... luego se perdió en algún hilo de Slack o algo así.

Pero has cambiado la estructura; has cambiado el nombre de «equipo de plataforma» a «grupo de plataformas». ¿Por qué? Sí.

¿Por qué se trata ahora de una plataforma que agrupa a varios elementos? Bueno, si me permiten, me gustaría mencionar la segunda edición... Mm-hmm... para quienes aún no la hayan visto.

Así que la idea era no modificar la primera edición porque, como dije antes, todo lo que había en ella sigue siendo válido, básicamente. Quizá ya no se hable tanto de DevOps como en 2019, pero las ideas siguen siendo válidas. Y lo que hicimos fue incluir un nuevo prólogo, que en su mayor parte echa la vista atrás a los cinco seis años transcurridos desde que se publicó la primera edición, y cuáles fueron los errores que cometimos o los aspectos que no quedaron lo suficientemente claros en el primer libro, como cuáles eran los principios que lo sustentaban, y luego cosas como la forma en que las diferentes empresas, como Telenet, que mencioné antes, adoptaron los patrones de diferentes maneras, aplicando los tipos de equipos, pero a nivel de tribu.

Además, hay un nuevo epílogo que, en cierto modo, establece una mayor conexión con la situación actual y los próximos años en lo que respecta a la IA, y analiza cómo esto cambia —o no— nuestra forma de concebir la dinámica organizativa. También se han añadido diez nuevos casos prácticos, así como esa nota sobre la agrupación de plataformas. Lo que ocurrió con la primera edición es que queríamos que fuera sencilla.

Así que la idea del equipo de la plataforma, por un lado, es mantener la sencillez; el equipo de la plataforma como otro tipo de equipo, porque hay quien dice: «Bueno, es una especie de equipo de producto, ya que se trata de un producto interno». Sí, pero nos pareció que había suficientes diferencias, porque tienes clientes internos, no externos, y a menudo estás prestando servicios que, desde un punto de vista técnico, suelen ser complejos. Estábamos hablando de muchos de ese tipo de servicios técnicos.

Lo que se nos pasó por alto, y quizá sea algo de lo que no me di cuenta cuando se publicó la primera edición, es que la idea de un «equipo de plataforma» a veces se malinterpretaba como si se tratara de un único equipo responsable de toda una plataforma. Y, por supuesto, con el tiempo, las plataformas internas tienden a crecer. Si tienen éxito, lo cual es algo positivo, tenderán a crecer.

Y, al menos para mí, fue, supongo, una de esas cosas que me parecían bastante obvias: que se necesitarían varios equipos y que se necesitaría una plataforma más grande. Si es pequeña y tienes uno o dos equipos, no hay problema. Pero si empiezas a tener tres, cuatro, cinco, o si empiezas a tener básicamente más de, diría yo, 30 personas trabajando en la plataforma, tienes que pensar cuáles son las diferentes vías dentro de la plataforma, ¿no?

¿Cuáles son los distintos servicios que permiten organizar la estructura de la plataforma desde una perspectiva de equipo, de forma similar a como se hace con los productos? Tenemos que identificar diferentes flujos, ya sean clientes o internos. Y ahí es donde, en algunas organizaciones, hablábamos con ellos y nos dábamos cuenta de que tenían un equipo de plataforma enorme, con docenas de personas, y, por supuesto, estaban extremadamente ocupados, sobrecargados, corriendo de un lado a otro intentando arreglar cosas y entregar novedades, pero todo era muy improvisado.

Por eso, en la segunda edición, intentamos dejar mucho más claro que, de hecho —y quizá esa sea una mejor forma de plantearlo—, siempre se trata de una agrupación de plataformas. Vas a tener un conjunto de equipos, y estos deben tener responsabilidades y límites bien definidos entre ellos. No significa que sean totalmente independientes todo el tiempo, pero no deberíamos tener cinco equipos que tengan que coordinar su trabajo constantemente.

Así que, si partimos de la idea de que se trata de una agrupación de plataformas, aunque a veces solo haya un equipo en esa agrupación, quizá esa sea una forma mejor de verlo, algo que se nos pasó por alto en la primera edición. Por otro lado, como resultaba más sencillo hablar de «equipos de plataforma», creo que eso también ayudó a las organizaciones a comprender la diferencia entre «plataforma» y «optimización» en lo que respecta al producto. Pero ahora, con suerte, ya está claro.

Sí, claro.

No, pero estoy de acuerdo, y es evidente que estoy pensando en cosas parecidas. Ahora mismo estoy escribiendo la segunda edición de mi primer libro, «The Enterprise Data Catalog», y es más o menos lo mismo, ¿no?, ya que la primera edición habla de un único catálogo de datos en una empresa y solo de uno. La realidad es que, en la mayoría de los casos, se suele tener varios catálogos de datos. Sí.

Y estarán integradas o ubicadas en distintas áreas de la empresa. Algunas utilizan un solo proveedor de servicios en la nube, otras solo una plataforma de datos concreta con su catálogo asociado. Es como si fuera algo totalmente natural.

Sí. Y supongo que es el privilegio de escribir una segunda edición. No es que haya muchos privilegios en eso.

Es un trabajo duro. Pero una de las ventajas es que puedes basarte en los conocimientos ya adquiridos de la primera edición, ¿no? Sí.

Así que habría sido difícil, supongo. Sí. Yo diría que, de hecho, es un buen indicio que te des cuenta de que en la segunda edición había algunas cosas de la primera edición que se habían malinterpretado.

Significa que se adoptaron, ¿no?, y que las organizaciones estaban aplicando esas ideas. Quizás es solo que algunas cosas no estaban tan claras como podrían haberlo estado. Pero eso es algo que, al igual que ocurre con el desarrollo de productos y servicios, te das cuenta de que eso era lo que pensábamos que tenía sentido.

En realidad, tenemos que adaptarnos y corregir el rumbo.

Así que, en cierto modo, veo la segunda edición como una forma de corregir el rumbo o de añadir más contexto y aportar nuevas perspectivas a lo que ya había en la primera edición. Mm-hmm. Por supuesto.

Y me gustaría entrar en detalles sobre esto; concretamente, en lo que respecta a la segunda edición, como has mencionado, hay muchos casos prácticos. Y creo que deberíamos analizarlos. Yo me he centrado en dos, pero puedes mencionar el tercero si quieres.

Pero... Claro... Creo que EBSCO, creo que es... Me llegan muchas notificaciones en otra plataforma y simplemente las estoy desactivando.

Lo siento. No te preocupes. Es solo mucho ruido.

Demasiadas peticiones de atención. Sí, exactamente. Ahí lo tenemos.

Bueno, ahí estás. Genial. En fin, hablemos primero de... ¿cómo se llama? EBSCO, el primer caso de uso.

¿Te refieres a la empresa EBSCO? Sí, EBSCO. EBSCO.

La razón por la que quería hablar de ese caso es que, obviamente, se trata de uno más pequeño, creo. Pero es interesante que también hayan estado trabajando con un marco para la creación de equipos, como Team Topologies. Han pensado en crear una estructura organizativa que les ayude a obtener mejores resultados, y esa es SafeAgile.

Pero en este caso... Sí... se les acabó un poco el potencial con SafeAgile. ¿Podrías explicarnos por qué y qué hicisteis? Sí...

¿Quién cambió su configuración? Así que yo no trabajé directamente en eso. Y, de hecho, en la mayoría de los casos prácticos —lo cual es interesante— de la segunda edición, no participamos directamente.

No es que fuéramos nosotros quienes les impusiéramos el cambio. Era la forma en que las propias empresas concebían la aplicación de las ideas y su propia transformación, y eso es realmente genial. Y luego, por distintos medios, acabamos enterándonos, o bien ellos vinieron a nosotros y nos contaron lo que habían hecho.

En algunos casos, habíamos impartido alguna conferencia o algún curso de formación. Pero, a menudo, en los casos prácticos de la segunda edición, no participamos directamente. Así que creo que eso también está muy bien.

EBSCO es uno de esos casos curiosos en los que, si le preguntaras a cualquiera de los aquí presentes, supongo que casi nadie habría oído hablar de EBSCO. Y entonces te das cuenta de que, en realidad, es una empresa bastante grande. Se dedican a ofrecer bases de datos de investigación e información para bibliotecas, universidades, etcétera.

Así que es uno de esos negocios de los que no se habla muy a menudo. Y lo que pasó es que habían estado utilizando Safe, diría yo, con bastante éxito. Obviamente, Safe es un marco que, en mi opinión, depende de si partes de una organización muy caótica en la que siempre hay retrasos y todo el mundo va de un lado para otro, intentando sacar el trabajo adelante, pero en la que siempre reina un gran caos.

Por supuesto, creo que Safe puede ayudarte a establecer cierta estructura y a descubrir cómo planificar mejor, y te aporta mucha claridad, diría yo, sobre las dependencias que existen entre equipos, entre dominios o entre flujos de valor. El problema con SAFe es que, en algún momento —y esto lo hemos visto no solo con EBSCO, sino también con otras empresas—, te ayuda a pasar de esa etapa inicial más caótica a algo más estructurado, un poco más o mucho más predecible.Pero en algún momento, deja de ser de ayuda en el sentido de que se centra mucho en gestionar las dependencias y no tanto en eliminarlas o en lidiar con los efectos de esas dependencias. Mm-hmm.

En resumen, acabas acostumbrándote. Vale, conocemos las dependencias. Sabemos que tenemos que hacer esta planificación para poder contar, por lo general, con un plan trimestral que establezca qué equipos van a tener que trabajar en qué iniciativas o funcionalidades, etcétera.

Así que, como ya he dicho, si partes de una situación en la que todo era un caos y no se cumplía ningún plazo, entonces sí, eso ayuda. Pero entonces te quedas estancado ahí. Y lo que hicieron muy bien en EBSCO fue que tenían unos indicadores realmente buenos, como los indicadores de lentitud, y analizaban dónde estaban los cuellos de botella, dónde estaban los tiempos de espera para entregar valor a nuestros clientes o para implementar cambios que, con suerte, serían valiosos para ellos.

Y así, ellos mismos empezaron a darse cuenta de que, vale, hemos mejorado mucho, pero nos hemos estancado un poco, ¿no? Habíamos llegado, digamos, al límite de lo que SAFe puede ofrecernos. Así que recurrieron a las topologías de equipo para empezar a abordar el tema: «Vale, no nos conformemos con las dependencias».

En realidad, tenemos que utilizar esos modelos para eliminar las dependencias que obstaculizan el trabajo y proporcionar capacidades internas que realmente ayuden a impulsar a los equipos. Y como contaban con una excelente telemetría organizativa interna —por así decirlo—, es decir, unos indicadores muy buenos, eso fue parte del motivo por el que los casos prácticos nos resultaron interesantes: pudieron comprobar cómo el uso de las topologías de equipo ayudó a mejorar esos indicadores.

Sí, exactamente. Y supongo que si tienes la certificación SAFe Agile, como yo y como muchos otros, intuyes que hay un límite máximo en cuanto a lo que puede ofrecer, ¿no? Mm.

He oído a gente referirse a él como un «monolito de marcos». No sé si te conviene usar ese término, dado que se trata de un marco de la competencia. Pero si le echas un vistazo a su página web, hay muchos conceptos que debes comprender y saber cómo se relacionan entre sí para poder...

No es una configuración sencilla. Por un lado, supone una gran inversión inicial y, además, en mi opinión, más allá de ese aspecto de la inversión, parece que te lleva a... Antes estábamos hablando de que tenemos que ser adaptables y, en cierto modo, evolucionar continuamente, y creo —y no soy ningún experto en SAFe, pero por lo que he visto— que parece llevarte a un punto en el que consigues este tipo de, sí, marco estable y monolítico, lo que sea que funcione dentro de ese ámbito, pero entonces, en cierto modo, no estás pensando realmente en cuál es el siguiente paso.

¿Cómo seguimos mejorando? Y, obviamente, están los trenes de lanzamiento y todo eso que, sí, creo que, como has dicho, lo reflejan bien. Ayuda hasta cierto punto, pero luego hay un límite máximo porque estamos vinculados a esos trenes de lanzamiento y, en cualquier caso, fue interesante.

En algún momento, SAFe tomó algunas ideas de las topologías de equipo, pero no otras, lo cual, en mi opinión... Mm. Sí, básicamente adoptaron los tipos de equipo, lo que creo que fue un paso adelante.

Pero eso no significa necesariamente que estés pensando en mejorar tu flujo simplemente por adoptar los tipos de equipo. Y si sigues teniendo esos trenes de lanzamiento, sigues acoplando —al menos temporalmente— gran parte del trabajo, lo que tiende a manifestarse también en un acoplamiento a nivel técnico, ¿no? Porque si de todos modos vamos a hacer un lanzamiento juntos en, digamos, cuatro semanas, ¿por qué debería invertir en hacer esto más modular y que pueda evolucionar de forma más independiente si, al final, tenemos que integrarlo todo?

Sí. Bueno, cambiemos un poco el tono de esta conversación y admitamos simplemente que, en mi opinión, SAFe Agile es un mosaico de metodologías. La verdad es que no sabía que habían tomado elementos de las topologías de equipo, pero eso es muy típico de ellos, ¿no?

También tomaron elementos de Lean y otros principios, así que, obviamente, si uno cree en eso, quizá pueda aportar mucho valor. Creo que puede hacerlo a un nivel básico, pero se vuelve muy complicado. Quería preguntarte por otro caso práctico, pero creo que se nos acaba el tiempo, así que, en su lugar, hablaremos del caso práctico de Adidas.

Me parece que su plataforma, la arquitectura de la plataforma digital, es realmente interesante, pero no tenemos tiempo. Es demasiado complicado... Sí... como para explicarlo en un par de minutos.

Así que, en lugar de eso, estaba pensando —estuvimos hablando un rato antes de salir en directo— y, por eso, quiero hacerte otra pregunta, una más general: has publicado estos libros en IT Revolution. Es una editorial fantástica. La casa editorial de «The Phoenix Project» y de muchos otros libros muy influyentes, aunque no publiquen muchos títulos.

¿Cómo entablaste la colaboración con ellos y cuál es, más o menos, la naturaleza de esa editorial? Sí. Bueno, se centran principalmente en ayudar a los líderes empresariales.

Y los libros que publican, como has dicho, son solo unos pocos al año. Es una editorial pequeña y se centran realmente en publicar libros que sean relevantes y tengan sentido para los líderes empresariales. Obviamente, cada editorial tiene su propia estrategia.

Algunos se basan en el volumen. Su prioridad es la calidad de lo que publican. Y, como has dicho, la razón por la que ya habían publicado algunos libros fundamentales, como «Phoenix Project», «Accelerate» y «From Project to Product», de Mik Kersten.

Así que pensamos que nuestro libro, cuya intención era... Pensamos que nuestro público objetivo inicial iban a ser los directivos de empresas, así como los líderes empresariales y los ingenieros y arquitectos sénior. Por eso encajaba muy bien con el público de IT Revolution.

Ya conocía a Gene Kim de antes, por mi trabajo con DevOps, así que sí, todo parecía encajar. Al menos, en aquel momento no estaba tan familiarizado con el mundo editorial y con los distintos enfoques de la publicación y la edición. Así que creo que tuvimos mucha suerte de que aceptaran, de que vieran el valor de nuestra propuesta y de que tuvieran un proceso editorial tan minucioso.

Así que si hubieras leído el primer borrador de «Team Topologies», te habría resultado difícil, porque, como le pasa a mucha gente que nunca ha escrito un libro, tenía una estructura bastante académica; y los editores de IT Revolution —les doy las gracias de todo corazón— nos ayudaron muchísimo. «Vale, convirtámoslo en una narración real que la gente pueda consumir y a la que pueda recurrir más adelante», como decías sobre la primera edición. Nuestro objetivo era también crear un libro que la gente pudiera leer y al que pudiera volver más adelante.

«Ah, recuerdo algo del capítulo seis que me vendría bien para mi situación actual», así que lo usamos como referencia. De hecho, nos ayudaron mucho a convertir ese primer borrador en una versión mucho mejor. Y confiamos en ellos porque al principio pensábamos: «Quieren destrozar nuestro trabajo». Así es como se siente, ¿verdad?

Cuando alguien te dice: «Tienes que reorganizar gran parte de lo que cuentas en el libro». Así que sí, esa fue más o menos la historia, y eso marcó una gran diferencia, creo, también en el éxito del libro, o al menos eso estoy seguro.

Sí. Y gracias también por compartir ese detalle. Se nos acaba el tiempo.

He visto una pregunta en la sección de preguntas y respuestas de Sabrina Sheila. No tenemos tiempo para revisarla ahora. Te la enviaré y quizá podamos responderla más tarde.

Pero, Manuel, quiero aprovechar para darte las gracias de todo corazón por estar aquí, en «Data Explored». Espero que los oyentes lo hayan disfrutado mucho. Yo, desde luego, sí.

Le deseo una vida fantástica a la segunda edición, y... gracias... por mantenerte en contacto. Nosotros lo haremos.

Muchas gracias. Ha sido un placer. Gracias.