En Roibase no hacemos standups síncronos desde hace 18 meses. En un equipo multidisciplinario de 12 personas (engineering, growth, design), las reuniones semanales bajaron por debajo de 3. Los ciclos se acortaron 22%, el tiempo de escalado de bloqueos bajó de 4 horas promedio a 90 minutos. Una sola razón: usar Linear no como issue tracker, sino como infraestructura de disciplina operacional.
En este artículo explicamos el cycle engine de Linear, el patrón de actualizaciones async diarias y los mecanismos de escalado de bloqueos con detalles concretos de setup. No es un hack de productividad: es arquitectura de workflow.
Cycle Engine: No Sprints, sino Ritmo
El concepto de cycle en Linear se confunde con sprints clásicos. La diferencia: sprint planning requiere una reunión, el cycle gira automático. Configurar un cycle bien significa eliminar la reunión de planificación semanal.
Nosotros trabajamos con ciclos de 2 semanas. Inicio: lunes. Cierre: viernes por la noche. En cada ciclo entra en juego este mecanismo automático:
- Regla de asignación automática: Los issues en Backlog con label "High" o "Critical" se mueven automáticamente al cycle iniciado. En la Triage view de Linear, los issues nunca se abren dentro del cycle — primero se refina el backlog, luego se asigna prioridad.
- Límite de WIP: Máximo 3 issues "In Progress" por persona. Abrir el cuarto envía una alerta a Slack vía automation personalizada. El equipo cumple esta regla: antes de empezar un nuevo issue, uno debe estar "Done" o "Blocked".
- Velocity tracking: El analytics built-in de Linear muestra completion rate y point velocity. Nuestra métrica de oro: "scope creep ratio" — número de issues agregados dentro del cycle / issues planeados. Si pasa 15%, el siguiente cycle tiene refinement más agresivo.
La roadmap view gana potencia aquí: si los cycles giran en ritmo predecible, proyectar 3 meses adelante es posible. No es predicción: es proyección matemática basada en velocity.
Ciclo de Cierre: Retrospectiva Async
Cuando cierra el cycle, sin reunión. Se abre un issue "Cycle Review" en Linear. El template es:
## Completed
{Linear rellena automáticamente}
## Spilled Over
{Issues no terminados — ¿por qué?}
## Velocity
{Porcentaje de completación de puntos}
## Blockers Escalados
{Número de issues con tag Blocker + tiempo de escalado}
## Next Cycle Adjustment
{Decisión de aumentar/reducir scope}
Cada miembro del equipo rellena su sección en 24 horas. La reunión de retrospectiva síncrona solo ocurre si en 2 ciclos consecutivos la velocity cae más de 30% — eso pasa 1-2 veces al año.
Patrón de Actualización Diaria: Contexto, no Status
La versión pobre del standup async es así: "Ayer hice X, hoy haré Y, ¿bloqueos?" Se pega en Slack, nadie lo lee. Esa información ya está en Linear — repetirla no tiene sentido.
Diseñamos la actualización diaria como "transferencia de contexto". Cada mañana a las 09:30, el bot de Linear pregunta en Slack (DM, no público):
- ¿En qué issue cambió el scope? (Tomaste una decisión técnica diferente a la planeada)
- ¿Qué issue espera input de otro? (Dependencia abierta)
- ¿Hoy quién está en modo "Deep Work"? (Horario sin meetings)
Responder es opcional — pero si hay scope shift en un issue y no lo reportas, en la code review aparece "¿por qué se diseñó así?" Haber transferido contexto async acorta el review.
En la pestaña "Activity" de cada issue en Linear, estas actualizaciones se ven automáticamente — no necesitas scrollear Slack. Para entender el contexto de un issue, lo abres y ahí están los últimos 3 días de transferencia de contexto.
Deep Work Block e Interrupt Cost
Quien marca "Deep Work" en la actualización matinal automáticamente pone el status de Slack en "Do Not Disturb" (integración Zapier). Las notificaciones de Linear también se suspenden 4 horas. Este mecanismo dio este resultado: average response time en DM's subió de 12 minutos a 38 minutos — pero el merge time de código bajó 18%. Menos interrupciones, output de más calidad.
En el trabajo de markalaşma de Roibase hay ritmo similar: la responsabilidad creativa no se corta con meetings sin contexto, los sprints de diseño avanzan async dentro del cycle.
Escalado de Bloqueos: Regla de 2 Horas
"Blocker" en muchos equipos queda vago. Nosotros lo definimos con regla numérica: es blocker lo que no puedes resolver en 2 horas o que necesita input de otro para continuar.
En Linear, marcas el issue como "Blocked", y automáticamente comienza este flujo:
- Primeros 30 minutos: El assignee escribe en Slack el detalle del bloquer (qué dependencia, qué espera de quién).
- 1 hora: La persona esperada responde — o lo resuelve en el acto, o commits "lo haré en X tiempo".
- 2 horas: Si no se cumple el commit, el issue escala automáticamente al team lead.
El resultado numérico de este patrón: 78% de los blockers se resuelven en 90 minutos. Antes, se hablaban en standup diario. Ahora se resuelven sin hablar.
La relación "Blocked by" de Linear es crítica aquí — si un issue depende de otro, cuando se cierra el upstream, el downstream cambia automáticamente a "Ready". Sin tracking manual.
La Semana Sin Reuniones: Números Reales
Hace 18 meses, el promedio semanal era 8.2 horas de reuniones por persona. Ahora: 2.1 horas. Las reuniones restantes son:
- Kick-off de cycle (cada 2 semanas): 30 minutos, solo alineación de prioridades top-level
- Sync con clientes (semanal): 45 minutos, stakeholder externo obligatorio
- Design critique (cada 2 semanas): 60 minutos, review en Figma — no se puede hacer async porque la discusión en tiempo real es necesaria
No todo tiene que ser async — pero convertir en meeting lo que puede ser async tiene costo. El patrón Linear + actualización async reduce ese costo.
En la encuesta de satisfacción del equipo (cada 6 meses) la puntuación de "meeting load" pasó de 3.2/10 a 7.8/10. "¿Es el ritmo del cycle predecible?" puntuó 8.9/10 — antes de Linear era 5.1/10.
Contraargumento: ¿Async Funciona para Todos?
Este sistema es overkill para equipos de 5 personas. El cycle engine de Linear es overhead — un Trello manual es más práctico. El standup async también sobra. Pero a 10+ personas, el costo de meetings explota exponencialmente. Entonces hay que imponer disciplina.
Otro límite: roles facing-customer (sales, support) no pueden ser fully async. Pero la operación engineering + design + growth sí — lo probamos con 12 personas.
Si usas Linear solo como issue tracker, este artículo no te da nada. Cuando lo usas como infraestructura de disciplina operacional — cycle management, daily update pattern, escalado de bloqueos — las reuniones síncronas dejan de ser necesarias. Los tres juntos reducen el meeting time. En Roibase bajó: hay evidencia numérica. En tu equipo también puede bajar — pero hay que instalar disciplina, no solo herramientas.