Cómo gestionar un equipo de ingeniería async-first
Guía práctica para equipos de ingeniería async-first: normas de comunicación y rituales de decisiones que realmente funcionan.
By Ellis Keane · 2026-04-06
Cuando el telégrafo acabó con el informe diario
En 1844, Samuel Morse envió el primer mensaje telegráfico entre Washington y Baltimore, y en menos de una década, las empresas que dependían de los informes diarios en mensajero empezaron a operar de forma diferente. No porque quisieran ser «telégrafo-first» (nadie lo decía así), sino porque la restricción había cambiado. La información podía viajar más rápido que un caballo, y los rituales construidos alrededor de los caballos fueron quedando silenciosamente obsoletos.
El paralelismo con la gestión de un equipo de ingeniería async-first es incómodamente directo. Tenemos Slack, Linear, GitHub, Notion y otros siete tools que mueven información a la velocidad de un webhook, y sin embargo la mayoría de los equipos siguen organizando su jornada en torno a rituales sincrónicos diseñados para cuando había que estar en la misma sala para compartir contexto: el standup diario donde todos recitan sus tickets de Jira a un manager que ya tiene exactamente el mismo tablero abierto en un segundo monitor; la «sincronización rápida» que dura 45 minutos porque tres personas comparten pantalla de forma secuencial mientras el resto mira el móvil.
Para un equipo de ingeniería pequeño como el nuestro – cuatro personas en tres zonas horarias – reconocer que la restricción había cambiado fue la parte fácil. Reconstruir los rituales llevó más tiempo.
Cómo es realmente un equipo de ingeniería async-first
Ingeniería async-first significa que el modo de comunicación predeterminado de tu equipo es asíncrono. Las decisiones se escriben. El estado es visible sin necesidad de preguntar. El contexto está documentado donde las personas pueden encontrarlo según su propio horario. Las reuniones siguen existiendo, pero son la excepción a la que entras deliberadamente, no el estándar del que tienes que salirte.
Lo que no significa es que nadie hable nunca en tiempo real – eso sería absurdo y, sinceramente, un poco solitario. Las revisiones de diseño, la resolución de conflictos, las sesiones de brainstorming y las discusiones arquitectónicas matizadas donde necesitas leer el lenguaje corporal y dibujar en pizarras siguen siendo sincrónicas, y eso está bien. La distinción es qué modo eliges primero cuando necesitas comunicar algo, y para la mayoría de las cosas en un equipo de ingeniería, la respuesta debería ser escribirlo en lugar de programar una llamada, porque un comentario bien redactado en Linear a las 14:00 en Buenos Aires sigue siendo perfectamente legible a las 9:00 en Madrid al día siguiente.
Async-first no significa async-only. Significa que tu predeterminado es asíncrono, y optas por la comunicación sincrónica de forma deliberada cuando la situación realmente lo requiere.
Los cuatro pilares (que parecen obvios hasta que los intentas)
Durante el último año, hemos estado construyendo Sugarbug como un equipo de cuatro personas repartidas entre la costa este de EE.UU. y Europa. Lo que realmente hizo funcionar nuestro equipo de ingeniería async-first no fueron las herramientas ni las políticas – fueron los hábitos. Aquí están los cuatro que se mantuvieron.
1. Escribir las decisiones donde ocurrieron
Casi nadie lo hace de forma consistente. Se toma una decisión en un hilo de Slack. Alguien dice «de acuerdo, vamos con la opción B.» Y entonces... se queda ahí. En un hilo que será prácticamente imposible de encontrar en tres semanas.
La solución no es un registro de decisiones (bueno, no principalmente). La solución es una norma: quien tome la decisión final escribe un resumen de una frase con lo que se decidió y por qué, en la herramienta donde vive el trabajo. Si decidiste cambiar el formato de la respuesta de la API, ese resumen va en el issue de Linear o en la descripción del PR de GitHub, no en un hilo de Slack o en una transcripción de reunión que nadie volverá a ver.
Lo aprendimos a las malas: un PR estuvo en revisión tres días porque el revisor no sabía que ya habíamos decidido usar renderizado en el servidor para esa página – la decisión estaba enterrada en un hilo de Slack de la semana anterior, y nadie la había escrito en el issue. El revisor dejó seis comentarios sobre las compensaciones de la hidratación en el cliente que ya estaban resueltas, el autor se frustró, y perdimos casi una semana en una conversación que debería haber llevado diez segundos si el contexto hubiera estado adjunto al trabajo desde el principio.
Después de eso, dejamos de intentar mantener un documento de decisiones separado (que había funcionado durante unas dos semanas antes de convertirse en una cosa más que nadie actualizaba) y empezamos a escribir las decisiones directamente en el issue. Diez segundos de esfuerzo, y sobrevive porque está unido al trabajo, no flotando en un meta-documento que nadie consulta.
2. Hacer el estado visible, no reportado
Para nuestro equipo, la reunión de actualización de estado era el ritual sincrónico más costoso – cada persona narra lo que hizo ayer y lo que hará hoy mientras todos los demás escuchan a medias esperando su turno. En un equipo async-first, el estado debería ser algo que puedes ver, no algo que alguien tiene que decirte.
Esto significa que tu herramienta de gestión de proyectos debe reflejar la realidad. Si un issue de Linear está en «En progreso», debería ser porque alguien está trabajando genuinamente en ello ahora mismo, no porque lo movió allí el lunes y no lo ha tocado desde entonces. Los PRs de GitHub deberían tener títulos descriptivos e issues vinculados. Los archivos de Figma deberían tener nombres claros que indiquen qué está en progreso y qué está aprobado.
Qué hace visible el estado
- PRs vinculados a issues – Cualquiera puede ver qué código corresponde a qué tarea
- Nomenclatura clara de ramas –
feat/user-onboarding-flow dice más que fix-stuff
- Estados de issues actualizados – Mueve los tickets cuando el trabajo realmente avanza, no durante los standups
- Resúmenes semanales escritos – Una persona escribe un digest, todos lo leen de forma asíncrona
Qué mantiene el estado invisible
- Actualizaciones solo verbales – La información desaparece en el momento en que termina la reunión
- Las reuniones de estado como registro oficial – Si no se dijo en el standup, no ocurrió
- Tableros desactualizados – Un tablero Kanban que no se ha tocado desde el lunes
- Contexto bloqueado en DMs – Dos personas lo saben, todos los demás adivinan
3. Definir ventanas de respuesta, no tiempos de respuesta
Una de las ansiedades más sutiles de la comunicación asíncrona es la espera abierta. Envías un mensaje y no sabes si recibirás respuesta en veinte minutos o mañana por la tarde. La incertidumbre es peor que el retraso real.
La solución no es exigir respuestas más rápidas (eso solo recrea la cultura sincrónica con pasos adicionales). Es establecer expectativas explícitas sobre las ventanas de respuesta para distintos tipos de comunicación. En nuestro equipo se ve más o menos así:
- Mensajes de Slack en canales públicos: En un plazo de 4 horas laborables
- Revisiones de PRs: En un día laborable
- Comentarios en issues de Linear: En un día laborable
- DMs marcados como urgentes: En 1 hora durante el horario laboral
- Todo lo demás: En 2 días laborables
Las ventanas específicas importan menos que el hecho de que existan y que todo el mundo las haya acordado. Una vez que el ritmo es explícito, la ansiedad del «¿lo habrá visto?» desaparece, y la gente deja de enviar mensajes de seguimiento después de treinta minutos de silencio.
4. Proteger el tiempo sincrónico para lo que realmente lo necesita
Algo que no esperábamos: las reuniones que conservamos mejoraron notablemente. Cuando una reunión es la excepción en lugar del estándar, las personas llegan preparadas y comprometidas porque saben que esa es la única ventana que tienen para resolver algo juntos.
Mantuvimos tres tipos de reuniones sincrónicas:
- Sincronización semanal del equipo (30 minutos máximo) – No actualizaciones de estado, sino bloqueos, preocupaciones transversales y conversaciones del tipo «¿alguien más cree que esta decisión arquitectónica nos va a pasar factura?»
- Revisiones de diseño – Algunas cosas genuinamente necesitan retroalimentación visual sincrónica
- Sesiones de pair programming – Cuando dos personas están atascadas, hablar juntos sigue siendo más rápido que el ida y vuelta asíncrono
Todo lo demás que antes era una reunión se convirtió en una propuesta escrita, un vídeo de Loom o un hilo de comentarios en el issue relevante. Nuestro calendario pasó de parecer una partida de Tetris a algo que un ser humano podría organizar realmente a su alrededor – lo cual, resulta, es exactamente el punto de tener un calendario.
stat: "3 reuniones/semana" headline: "Desde 12" source: "El calendario real de nuestro equipo después de adoptar async-first"
La parte de la que nadie te advierte
La parte difícil de async-first no son las normas de comunicación ni la configuración de herramientas. Es el ajuste emocional. Cuando eliminamos nuestro standup diario, uno de nuestros ingenieros mencionó sentirse «extrañamente culpable» por empezar trabajo profundo a las 10 de la mañana sin haberse puesto al día con alguien. Otro dijo que el silencio en Slack antes del mediodía daba la sensación de que nadie estaba trabajando, aunque GitHub mostraba commits llegando cada hora.
Esta es la parte de la naturaleza humana del problema, y no tiene una solución a nivel de sistema. Lo que nos ayudó fue hablar de ello abiertamente. Hablamos sobre el hecho de que el trabajo asíncrono puede sentirse solitario a veces, y que está bien llamar a alguien simplemente porque quieres hablar con un humano sobre el problema que estás resolviendo. La norma no es «nunca llames» – es «no exijas una llamada para cosas que no la necesitan».
Algunas personas del equipo genuinamente prefieren más interacción sincrónica, y acomodar eso no es un fracaso de la filosofía async-first – es reconocer que las preferencias de comunicación son personales, y la adhesión rígida a cualquier modo único es su propio tipo de disfunción.
La parte difícil no es configurar flujos de trabajo asíncronos. Es sentirse cómodo con el silencio entre mensajes, y confiar en que tus compañeros están trabajando aunque no puedas verlos hacerlo. attribution: Ellis Keane
Hacer que funcione: los primeros 30 días
Si estás haciendo la transición de un equipo existente al modelo de equipo de ingeniería async-first, el primer mes es donde se arraiga o colapsa silenciosamente de vuelta a «mejor hacemos una llamada rápida». Aquí está lo que funcionó para nosotros como una línea de tiempo aproximada:
Semana 1: Escribe las normas de comunicación. Literalmente – un documento de una página que diga «así es como nos comunicamos, estas son las ventanas de respuesta esperadas, esto es lo que justifica una reunión.» Compártelo, discútelo de forma sincrónica (sí, la ironía) y consigue la aceptación del equipo.
Semana 2: Cancela o convierte tres reuniones recurrentes. Elige las que sean más obviamente actualizaciones de estado disfrazadas y reemplázalas con un formato escrito. No canceles todo de golpe – la gente necesita una rampa gradual, no un precipicio.
Semana 3: Audita la higiene de tus herramientas. ¿Están los issues de Linear realmente actualizados? ¿Son útiles las descripciones de los PRs? ¿Se están escribiendo las decisiones en los lugares donde ocurre el trabajo? Si no es así, esta es la semana para establecer esas normas. Asigna a alguien como «campeón async» que recuerde suavemente a las personas cuando se toma una decisión verbalmente pero no se escribe.
Semana 4: Retrospectiva (asíncrona, por supuesto). Envía un formulario sencillo: «¿Qué está funcionando? ¿Qué no? ¿Qué echas de menos?» Las respuestas te sorprenderán – algunas personas amarán la tranquilidad, otras tendrán dificultades. Ajusta las normas basándote en retroalimentación real, no en teoría.
- [x] Escribir documento de normas de comunicación
- [x] Definir ventanas de respuesta para cada canal
- [ ] Cancelar o convertir 3 reuniones de estado
- [ ] Auditar higiene de herramientas (issues, PRs, documentos de decisiones)
- [ ] Asignar campeón async para la transición
- [ ] Realizar retrospectiva asíncrona después de 30 días
- [ ] Ajustar normas basándose en el feedback del equipo
Cuándo async-first es la elección equivocada
Async-first es una mala opción en varias situaciones comunes. Si tu equipo son tres personas sentadas en la misma oficina, la comunicación sincrónica probablemente está bien y la sobrecarga de formalizar normas asíncronas estaría resolviendo un problema que no tienes. Del mismo modo, si tu equipo está en una crisis genuina – producción caída, un lanzamiento crítico inminente o estás pivotando la dirección del producto – ese es territorio sincrónico, y pretender lo contrario sería dogmático en lugar de práctico.
Async-first funciona mejor para equipos distribuidos en zonas horarias, equipos de más de unas cinco personas (donde la explosión combinatoria de la coordinación sincrónica empieza a doler) y equipos que prefieren escribir código a narrar lo que entregaron en una reunión sobre lo que entregaron. Si eso te describe, la inversión en normas asíncronas se amortiza en el primer mes, principalmente en horas de ingeniería recuperadas que solían desaparecer en el complejo industrial de las reuniones.
El telégrafo no eliminó la conversación cara a cara – simplemente hizo innecesario el viaje diario del mensajero. Eso es todo lo que hace async-first para un equipo de ingeniería: retira los rituales que solo existían porque las herramientas aún no habían alcanzado al mundo, y protege las conversaciones que realmente importan.
Preguntas frecuentes
Q: ¿Cómo gestionáis las revisiones de código en un equipo de ingeniería async-first? A: Estableced un SLA de revisión explícito (en nuestro caso es un día laborable) y haced que las descripciones de los PRs hagan el trabajo pesado – explicad no solo qué cambió sino por qué, vinculad el issue relevante y señalad cualquier cosa en la que el revisor deba centrarse. El mayor punto de fallo en las revisiones asíncronas es un PR que lleva tres días parado porque el revisor necesita contexto que solo existe en la cabeza de alguien. Escríbelo – o págalo después.
Q: ¿Ayuda Sugarbug con los flujos de trabajo async-first? A: Ayuda con el problema específico de que el contexto quede fragmentado entre herramientas – una decisión en Slack, una tarea en Linear, un comentario de diseño en Figma. Sugarbug conecta esas señales para que el estado sea visible sin que nadie tenga que narrarlo en una reunión. No es la única forma de resolver ese problema (también podrías ser muy disciplinado en vincular todo manualmente), pero lo construimos porque nos cansamos de la versión manual.
Q: ¿Cuál es el mayor error que cometen los equipos al adoptar async-first? A: Tratarlo como un cambio de política en lugar de un cambio de hábitos. Puedes escribir un documento de «normas de comunicación» precioso, pero si las personas no actualizan realmente sus issues de Linear ni escriben las decisiones en los PRs, simplemente habrás eliminado las reuniones sin reemplazar el flujo de información. Las normas tienen que convertirse en memoria muscular, lo que lleva aproximadamente un mes de recordatorios suaves y constantes.
Q: ¿Cómo gestionáis los problemas urgentes de producción en un equipo async-first? A: No los gestionas de forma asíncrona – ese es todo el punto de «async-first, no async-only». Define una ruta de escalada clara: un canal de Slack dedicado o PagerDuty para emergencias reales, con el entendimiento de que todo lo demás sigue las ventanas de respuesta normales. La distinción clave es entre «urgente» (producción caída) y «quiero una respuesta ahora» (que generalmente es impaciencia, no urgencia real).
Q: ¿Puede Sugarbug reemplazar completamente las reuniones de standup? A: Puede reemplazar la parte de recopilación de información – el ritual de «¿qué hizo todo el mundo ayer?» – porque ese contexto ya fluye a través de GitHub, Linear y Slack. Lo que no puede reemplazar es la parte de conexión humana, por eso seguimos manteniendo una breve sincronización semanal para las conversaciones que se benefician de estar en la misma sala (virtual).
Recibe inteligencia de señales directamente en tu bandeja de entrada.