El rol de PM que dejé tenía 650 documentos preparados para quien viniera después. Ninguno decía lo que el equipo realmente iba a necesitar.
Quiero escribir sobre transiciones — qué pasa cuando alguien deja un rol y otra persona ocupa ese mismo rol. No tanto sobre el proceso de handoff. Más bien sobre lo que la persona nueva carga sin que nadie se lo haya entregado, y que los documentos no podían capturar.
Voy a usar una transición de PM que viví directamente, pero el patrón es más amplio. Los cambios de vendor hacen esto. Los cambios de liderazgo hacen esto. Un diseñador nuevo entrando a un equipo senior hace esto. La mecánica es la misma: un rol no es solo un conjunto de responsabilidades, es un conjunto de relaciones que llevaron meses negociar, y esas relaciones no migran cuando migra la persona.
La ficción del handoff
La historia estándar del handoff es técnica. El que se va escribe documentación. El que llega lee documentación. La información se transfiere. La continuidad se preserva. Para esto sirve la documentación.
En mi caso, esa parte salió bien. A lo largo de siete meses escribí más de 650 documentos — decisiones de arquitectura, specs de requirements, notas de reuniones, evaluaciones de vendors, decision logs. Cuando me fui, el nuevo PM podía rastrear cualquier decisión mayor hasta su rationale, cualquier feature hasta sus requirements, cualquier relación de vendor hasta el historial de negociación. La documentación, por estándares de la industria, era excesiva.
No fue suficiente.
Lo que la documentación captura es qué se decidió y por qué lo decidimos. Lo que no captura, porque no puede, es cómo se sintió el equipo respecto a la decisión. De quién el buy-in fue real y de quién fue performativo. A qué ingeniero el PM anterior le confiaba el push-back contra specs malas. A qué stakeholder había que decirle las cosas dos veces antes de que se acordara. El mapa no documentado de quién manejaba qué — ese mapa vivía en mi cabeza, y cuando me fui, se fue conmigo.
Lo que la persona nueva realmente hereda
El nuevo PM caminó hacia la misma descripción de puesto que yo había tenido. Heredó la misma documentación. También heredó otras cinco cosas, ninguna de las cuales estaba en la lista del handoff.
La topología de confianza. Todo equipo tiene un mapa silencioso de quién es de confianza para qué. Hablá con este ingeniero cuando el problema sea de base de datos; hablá con aquel ingeniero cuando sea front-end. Las reviews de esta diseñadora son ley; las de aquella son consultivas. Este stakeholder te va a decir que sí en una reunión y te va a mandar un mail con un no el lunes. Yo había negociado todo eso a lo largo de meses. El PM nuevo lo tenía como pizarra en blanco. Su primer mes fue una serie de apuestas de confianza que no sabía que estaba haciendo.
Los canales de comunicación. Algunas decisiones en este equipo pasaban por Slack DM. Otras por syncs agendados. Otras por un canal de Telegram al que me habían sumado en la semana tres y que para la semana treinta había olvidado que existía. La documentación listaba los canales oficiales. La realidad era un mapa por capas de canales no oficiales, cada uno con sus propias convenciones de tiempo de respuesta y tono. Los canales son el sustrato de las decisiones; no podés tomar decisiones sobre un sustrato cuya existencia ignorás.
Los patrones de culpa. La última vez que hicimos un release un viernes, pasó esto. La última vez que le prometimos una fecha a este stakeholder, nos la cobró durante seis meses después del slip. Los equipos recuerdan. La documentación generalmente no escribe los patrones de culpa porque son incómodos. Pero los patrones de culpa son una predicción de alta resolución de qué va a resistir el equipo a continuación, y un PM nuevo entrando fresco va a tropezar accidentalmente con todos en el primer trimestre.
El contexto de decisión que los docs no capturan. El ADR dice elegimos filtrado híbrido. No dice elegimos filtrado híbrido porque el lead engineer tenía una opinión fuerte de que la alternativa iba a generar carga de mantenimiento, y overridear su opinión en la semana tres iba a costar más de lo que iba a comprar. El peso político de cada decisión — quién la pidió, quién aceptó a regañadientes, cuánto hubiera costado la alternativa en términos humanos — no entra en los ADRs porque los ADRs se escriben para gente de afuera. El subtexto político es lo que mueve al equipo.
La postura del equipo. Algunos equipos tienen pesimismo de fábrica; otros, optimismo. Algunos están saliendo de un fracaso reciente y todavía se sobresaltan; otros vienen de una victoria reciente y se sobreestiman. El equipo que dejé tenía una postura particular que yo había ayudado a formar a lo largo de meses — cuidadoso con el scope, ansioso por la calidad, alérgico a las sorpresas. El nuevo PM heredó esa postura, no sabía que la había heredado, y leyó varias de las interacciones de sus primeras semanas con un lente que no era el suyo.
Por qué esto es un problema de diseño, no solo de proceso
La mayoría de la literatura sobre transiciones las trata como un problema de proceso. Mejores documentos de handoff. Períodos de overlap más largos. Semanas de shadow más estructuradas. Todo eso es real y ayuda.
Pero el problema más profundo es que el sistema dentro del cual opera un equipo tiene tanto una forma explícita (organigrama, documentación, procesos, codebase) como una forma implícita (topología de confianza, canales de comunicación, patrones de culpa, contexto de decisión, postura). La forma explícita se transfiere vía documentación. La forma implícita se transfiere vía tiempo pasado adentro de ella — y la persona que recién llegó todavía no pasó tiempo.
La interfaz entre lo explícito y lo implícito es exactamente donde vive el diseño. El producto que diseñé para ese equipo tenía una forma particular porque el equipo tenía una postura particular. Las decisiones que había tomado sobre scope de features, sobre trade-offs de UX, sobre qué edge cases empujar y cuáles diferir — esas decisiones eran legibles para mí porque había absorbido la postura del equipo a lo largo de meses. Eran menos legibles para cualquier otra persona. Cuando me fui, los docs explicaban qué había diseñado pero no por qué esos trade-offs particulares se sentían correctos en ese momento.
Por eso el diseño que se transfiere sin contexto tiende a derivar. No porque el nuevo diseñador haga peores elecciones — muchas veces hace mejores — sino porque la coherencia del diseño anterior dependía de un contexto que ya no está en la sala.
Qué debería hacer realmente la persona que llega
Lo más útil que vi hacer a personas que recién llegaban, en mis propias transiciones y en otras que vi de afuera, es resistir las ganas de hacer cosas en las primeras semanas. Leer la forma heredada es trabajo real. Parece nada. No produce artefactos. Pero es la única forma de adquirir el mapa implícito que hace que el explícito tenga sentido.
Concretamente:
- Escuchá qué decisiones se vuelven a litigar y cuáles no. Las que se vuelven a litigar tienen consenso político débil; los docs pueden decir que están cerradas pero el equipo no las aceptó.
- Preguntale al equipo — por separado — quién decide X y quién decide Y. Las respuestas van a divergir. Las divergencias son la topología de confianza.
- Mirá lo que no se dice en los canales oficiales. Las decisiones más importantes en la mayoría de los equipos pasan por conversaciones laterales; los canales en los que estás no son los únicos que importan.
- Notá el clima emocional del equipo antes de introducir cambio. Un equipo en la semana ocho de un launch demorado va a recibir un cambio de proceso distinto que un equipo en la semana uno de uno exitoso.
Nada de esto está en los documentos de handoff porque nada de esto puede estar. Es el sustrato sobre el que flotan los documentos. Leerlo lleva semanas. Hacer cosas antes de leerlo es la fuente de la mayoría de las historias del estilo “el que llegó cambió todo y ahora no funciona nada.”
El principio
Un rol no es un conjunto de responsabilidades. Es un conjunto de relaciones que llevaron meses negociar, sobre un sustrato de convenciones, patrones de confianza y contexto no documentado que el ocupante anterior absorbió viviendo adentro de ellos.
Cuando el rol se transfiere, las responsabilidades se transfieren limpias. Las relaciones no. El sustrato no. La persona nueva hereda un trabajo que se parece al anterior y se siente distinto — porque, en las partes que importan, lo es.
Lo más generoso que la persona que se va puede hacer es nombrar las partes que no se transfieren. Lo más generoso que la que llega puede hacer es tomarse el tiempo para leerlas. La documentación ayuda. La documentación no alcanza.