Atlasingeniería

Liderazgo de personasOrganizaciónTema 1

Cómo se arman los equipos y cómo se hablan

La discusión sobre cómo dividir equipos suele quedarse en el organigrama. Lo que determina si la organización funciona no es la caja de cada equipo: es cuánta coordinación necesita cada uno para terminar algo.

Cada vez que una empresa crece, alguien dibuja cajas. Un equipo de frontend, uno de backend, uno de datos, uno de infraestructura. Es una división ordenada, fácil de explicar, y garantiza que cualquier cosa que un usuario quiera use tres equipos.

La pregunta que hay que hacerse no es cómo agrupar a la gente por especialidad, sino cuánta coordinación va a necesitar cada equipo para entregar algo completo. Esa cuenta se paga todas las semanas.

Cuatro tipos de equipo

El marco de Team Topologies propone cuatro formas, y la utilidad principal es poder decir en voz alta cuál es cuál, porque los problemas aparecen cuando un equipo cree ser uno y funciona como otro:

TipoQué haceCuántos hayRiesgo si se desvirtúa
Alineado al flujo de valorEntrega de punta a punta un pedazo de productoLa mayoríaQue necesite a otros para terminar cualquier cosa
De plataformaOfrece servicios internos que los otros consumen solosUno o pocosVolverse un equipo de tickets que aprueba todo
De capacidad específicaConcentra una especialidad difícil de conseguir, como seguridadPocos y chicosConvertirse en un cuello de botella obligatorio
De apoyo temporalAyuda a otro equipo a adquirir una capacidad, y se retiraTemporalesQuedarse para siempre y crear dependencia
La mayoría de los equipos debería ser del primer tipo. Los otros tres existen para que el primero pueda avanzar solo.

Tres formas de hablarse

Igual de útil que los tipos de equipo es nombrar el modo de interacción, y que sea temporal o permanente a propósito:

ModoCómo funcionaCuándo usarlo
ColaboraciónDos equipos trabajan juntos y estrecho por un tiempoCuando hay algo nuevo que descubrir; siempre con fecha de fin
Como servicioUno consume lo que el otro ofrece, sin coordinarseEl objetivo por defecto: mínima coordinación
FacilitaciónUno ayuda al otro a aprender algo y después se retiraTemporal, para transferir una capacidad
Colaborar es caro y a veces necesario. El error es dejarlo permanente cuando ya se podría consumir como servicio.

Antes de seguir, predecí

Un equipo de producto necesita cambios de infraestructura para cada funcionalidad nueva, y los pide por ticket. ¿Cuál es el mejor arreglo?

El tamaño y la carga mental del equipo

Dos ideas prácticas sobre el tamaño:

  • La comunicación crece mucho más rápido que la gente. Con cinco personas hay diez pares posibles; con diez, cuarenta y cinco. Por eso los equipos grandes se vuelven lentos aunque cada persona rinda igual.
  • Un equipo tiene un límite de cuánto sistema puede sostener. No es cuestión de voluntad: si un equipo es dueño de ocho servicios con tecnologías distintas, el contexto que hay que tener en la cabeza supera lo razonable y la calidad cae sola.

Contar la coordinación de cada entrega

Tres funcionalidades normales de un trimestre. La pregunta es cuántos equipos necesita cada una para salir.

1 / 6
La última fila es la que se paga todas las semanas. No se trata de que una división esté bien y la otra mal: se trata de que agrupar por especialidad hace que cualquier cosa que un usuario quiera cruce tres equipos, y esa cuenta no la paga el organigrama, la paga cada entrega.

Lo que preguntan sobre esto

Cierre

Autoevaluación

¿Lo entendiste?

¿Cuál es el problema de dividir equipos por especialidad técnica?
¿Cómo se sabe que un equipo de plataforma dejó de serlo?
¿Cuál debería ser el modo de interacción por defecto entre equipos?
¿Cuál es la señal de que un equipo sostiene más sistema del que puede?