Cómo estructurar tu equipo de tecnología
¿Cómo se estructura un equipo de tecnología? Quien arma uno, o lo hace crecer, se topa con la pregunta, y con la IA pesa más: un equipo chico ahora puede sacar mucho más, así que tiene que quedar claro quién es dueño de cada parte. Encontré una respuesta en un libro.
Team Topologies, de Matthew Skelton y Manuel Pais, trata de cómo armar los equipos que construyen software y de cómo fluye el trabajo entre ellos. Para el libro, la unidad que entrega es el equipo, no la persona.
El libro se apoya en dos ideas. La primera es la carga cognitiva: un equipo puede sostener solo cierta cantidad, y cuando es dueño de más, se pone lento. Por eso el libro ajusta las responsabilidades de cada equipo a lo que puede cargar.
Desde que salió la segunda edición, en 2025, llevaron el libro a la IA. Skelton escribe que la carga cognitiva de un equipo equivale a la ventana de contexto de un agente: si le das demasiado, pierde el foco, igual que un equipo.
La segunda es la ley de Conway. Una organización construye sistemas que se parecen a cómo se comunica su gente, así que equipos difusos suelen hacer software difuso. Y funciona al revés: si quieres cierto sistema, arma primero los equipos. El libro lo llama la maniobra inversa de Conway.
En el básquetbol pasa lo mismo. Cada uno sabe su rol: el tirador tira, el reboteador rebotea, y cuando todos aceptan el suyo, el juego fluye. En Eleven Rings, Phil Jackson cuenta que lo que lo atrajo del triángulo ofensivo fue que le da a cada jugador "un rol vital que cumplir, además de un alto nivel de creatividad dentro de una estructura clara y bien definida". En Sacred Hoops escribió: "Los buenos equipos se vuelven grandes cuando sus miembros confían lo suficiente unos en otros como para entregar el 'yo' por el 'nosotros'". Team Topologies le pide lo mismo a los equipos que construyen software: roles claros, límites claros, equipos que confían unos en otros y el equipo antes que el individuo.
Cuatro tipos de equipo
Un equipo alineado al flujo, stream-aligned, es dueño de un flujo de trabajo de punta a punta, desde la idea hasta producción. La mayoría de los equipos deberían ser de este tipo.
Un equipo de plataforma construye servicios internos que los otros equipos usan por su cuenta, para que carguen menos.
Un equipo habilitador ayuda a otros equipos a adquirir una capacidad que no tienen, y después se hace a un lado.
Un equipo de subsistema complicado es dueño de una parte que exige conocimiento especializado profundo, para que los demás no tengan que cargarla.
Tres formas de relacionarse
Colaboración es cuando dos equipos trabajan muy cerca por un tiempo acotado para descubrir algo nuevo.
X como servicio es cuando un equipo entrega algo y el otro lo usa casi sin necesidad de conversar.
Facilitación es cuando un equipo ayuda a otro a aprender o a destrabarse.
La idea es elegir la forma a propósito, y cambiarla cuando las cosas cambian.
En mi trabajo anterior
Team Topologies fue el libro con el que armé los equipos.
También fue cuando entró la IA. Encontré Cursor, lo probé en un proyecto personal y lo llevé al equipo con un método estructurado. Los límites claros ayudaron: cuando un equipo sabe de qué es dueño, puede llevar la IA a su propio ámbito. Los agentes necesitaban contexto, skills e interfaces limpias con límites claros, e intentábamos darles lo mismo a los equipos.
El mejor ejemplo llegó a pocas semanas de un lanzamiento beta, cuando una nueva versión de la app necesitaba datos de mercado de toda la bolsa de Estados Unidos. Primero, cada equipo acordó la interfaz. El equipo de plataforma entregó la API de datos de mercado como un servicio, X como servicio en los términos del libro, y el frontend se construyó contra esa interfaz. Los datos nuevos entraron detrás de un adaptador que ya estaba, plug and play. Team Topologies de libro.
En mi trabajo actual
Al comienzo, el conocimiento vivía en las personas. La propiedad de los módulos estaba mezclada, y para entender una parte del sistema tenías que saber a quién preguntarle.
Al principio no lo teníamos todo claro, y nos reorganizamos cuando lo vimos. Dos equipos alineados al flujo son dueños de los módulos del producto y del flujo de trabajo hacia los clientes. Un equipo de plataforma, que lidero, es dueño de lo que los sostiene: el harness de IA, con sus skills, subagentes y reglas, y el camino que recorre un cambio hasta producción.
En mi trabajo anterior teníamos Cursor y un método. Aquí tenemos Claude Code y un harness completo, mejor, más fuerte y más confiable que lo que teníamos.
Después el mapa creció hasta tener los cuatro tipos de equipo. Un equipo habilitador trabaja con los demás por un tiempo acotado para terminar de estandarizar la interfaz, las migraciones grandes, y cómo responde la API y cómo se mide. Un equipo de subsistema complicado está dedicado a una parte especializada del sistema.
El caso más claro de los equipos trabajando juntos fue un agente de cobranza, hecho en modo de colaboración sobre infraestructura y herramientas para agentes que ya existían. El equipo de plataforma construyó las evals, los guardrails y la conexión con WhatsApp a nivel de modelo de datos. Growth, un equipo alineado al flujo, hizo la integración con el proveedor de WhatsApp y el inbox. Core, el otro equipo alineado al flujo, construyó el agente: su prompt, su conocimiento y el endpoint con la información de cobranza de cada cliente. Cada pieza quedó en el equipo que era su dueño.
La propiedad quedó escrita en CODEOWNERS, en más de una docena de repositorios en un solo día, con un flujo de varios agentes en Claude Code. Ningún agente mergea. La última puerta de cada cambio es una persona que pide el archivo de propietarios.
Skelton ahora habla menos de propiedad y más de custodia: aunque los agentes escriban el código, un equipo humano responde por lo que llega a producción.
El equipo de plataforma
Pasamos el build del frontend a Vite, con Claude Code, y un deploy bajó de unos diez minutos a más o menos un minuto y medio. En el servidor, Bun se hizo cargo de la instalación y del build, y un deploy pasó de casi cinco minutos a poco más de dos.
La CI corre en GitHub Actions, y el deploy a AWS es parte del mismo pipeline. Las migraciones y los seeds necesitaban a una persona. Hace poco los dos entraron al pipeline, así que un release los corre solo, y el código nuevo sale únicamente cuando las migraciones terminan bien. Cada día hábil, el deployer de la semana mergea una rama de release de dev a main, con eso parte el release, y se queda atento por si algo falla. Lo demás ocurre solo.
X como servicio es la forma que más usamos. Construimos un servicio que extrae datos tributarios de un mercado nuevo, y un equipo alineado al flujo lo convirtió en producto sin tocar el scraper. Un paquete compartido resuelve fechas y zonas horarias, y los workflows de CI se escriben una vez y se llaman desde cada repositorio.
También buscamos que el primer día de cada persona nueva sea corto. Cada persona nueva entra a un solo equipo, con un dominio acotado que aprender, para que la carga cognitiva esté bajo control desde el inicio. Un CLI que es un fork del CLI de skills de código abierto de Vercel instala el harness, los repositorios, Obsidian y todo lo necesario para empezar a trabajar, en un solo comando. Nuestro último ingreso, un ingeniero junior, terminó su onboarding y su setup en menos de una mañana, y mergeó 12 pull requests en su primera semana.
El harness también cambió el volumen. El primer CLAUDE.md entró el 23 de marzo de 2026. En los 143 días siguientes mergeamos 2.870 pull requests, más o menos el doble de los 1.407 de los 143 días anteriores. Octubre de 2026 es nuestro mes más grande hasta ahora, con 1.312 pull requests mergeados faltando unos días, 102 de ellos de nuestro bot. Los pull requests mergeados no son creación de valor por sí solos. Aun así, impresiona lo que puede hacer un equipo de tecnología que hoy es de ocho personas.
El libro pide la plataforma más delgada que sirva, para que los equipos que construyen el producto carguen menos. Un equipo que saca una funcionalidad no tiene que pensar en cómo llega a producción. Es el equipo de plataforma que describe el libro.