Los artículos sobre stack de herramientas suelen terminar con "usamos X y es genial". Este es diferente — muestra los patrones de integración, criterios numéricos y tradeoffs detrás de la disciplina operacional que ha evolucionado durante 8 años en Roibase. Mientras Linear sprint velocity creció de 1.2 a 2.8, la jerarquía de docs en Notion pasó por 3 iteraciones, y el tiempo de respuesta async en Slack bajó de 4 horas a 45 minutos. Este cambio no vino de la selección de herramientas, sino del diseño sistémico que vincula estas herramientas a la cultura del equipo.
Linear: No es Velocity, es Costo de Cambio de Contexto
Cuando migramos de Jira a Linear en 2024, la expectativa no era velocidad — era reducir el costo de cambio de contexto. En Jira, el lifecycle de un issue significaba en promedio 9 cambios de pantalla, 3 menús desplegables, 2 webhooks manuales. En Linear, el mismo lifecycle requiere 2 atajos de teclado y 1 drag-drop. La diferencia no es tiempo, es economía de atención — un developer gasta 30 segundos pensando "¿dónde escribo este campo?" en lugar de 3 segundos resolviendo por reflejo.
En sprint planning no usamos la métrica de velocity — usamos distribución de cycle time. El analytics integrado de Linear oculta promedios engañosos como "4.2 días promedio" y muestra percentiles P50/P75/P90. Nuestro P90 cycle time es 11 días — aceptable porque los issues atípicos son generalmente blockers de dependencias. P50 es 2.8 días — la velocidad real del critical path. Mirar distribución en lugar de velocity transformó la presión de "acelerar" en disciplina de "predecibilidad".
El punto de integración: los webhooks de Linear escriben en tiempo real en la base de datos "Active Sprint" en Notion. Sin sincronización manual — cuando un developer cambia de status en Linear, la vista de roadmap en Notion se actualiza en 200ms. Este patrón de single source of truth permite que el PM consulte Notion antes de preguntar en Slack "¿dónde está ese issue?". En cultura async-first, hacer preguntas y esperar respuestas tiene costo — los webhooks lo reducen a cero.
Linear Triage Flow: Disciplina de Inbox Zero
En Linear existe disciplina de inbox zero — cada mañana a las 09:00 hay triage automático. Un nuevo issue cae a Linear Inbox, el PM lo clasifica en 30 minutos: label de prioridad + assignee + project link. Los issues sin clasificar después de 24 horas caen automáticamente al canal Slack #triage-needed. Esta forcing function mantiene la entropía del backlog bajo control — en 3 meses se abrieron 200 issues, 198 se clasificaron, latency promedio de triage 4.2 horas.
Notion: Jerarquía de Docs y Optimización de Tiempo de Lectura
Usamos Notion no como wiki, sino como decision log. Cada documento lleva 3 metadatos: decision-owner, last-reviewed-date, status (draft/active/archived). Si un status activo tiene más de 90 días sin revisión, un reminder automático cae a Slack. Así conforme escala se previene el deterioro de documentación — en 6 meses se crearon 180 páginas Notion, 12 se archivaron, el resto está bajo revisión activa.
La jerarquía tiene 3 capas: Company > Team > Project. Los docs a nivel Company (brand guideline, hiring process) todos pueden leer pero solo founder/lead editar. Los docs a nivel Team (sprint retro, tech debt registry) pueden editarlos los miembros del equipo. Los docs a nivel Project (feature spec, A/B test result) el assignee es propietario. Este modelo de permisos evita el caos de "todos editan todo".
Optimización de tiempo de lectura: Cada página Notion comienza con estimated reading time (palabras / 200). Los documentos más largos que 5 minutos deben incluir obligatoriamente un bloque TL;DR — escrito por el propietario del documento, no resumen IA. El TL;DR permite que el lector decida en 30 segundos "¿esto me interesa?". Con datos de 6 meses: después de agregar TL;DR, el bounce rate bajó de 42% a 18%.
Integración: Los archivos Figma se incrustan en Notion — pero como embed vivo, no screenshot. Cuando el designer cambia en Figma, la spec de producto en Notion se actualiza automáticamente. Este patrón elimina la pregunta "¿está actualizado el documento?". También los transcriptos de reuniones de Granola se publican automáticamente en Notion — cuando termina una reunión, en 2 minutos el resumen estructurado existe como página Notion.
Slack: Async-First, Sync Cuando es Crítico
En Slack no existe patrón de chat en tiempo real — cada canal es async-first. Cuando envías un mensaje, la expectativa es respuesta en 4 horas. Si necesitas respuesta más rápida, agregas mention @urgent — esto cambia el tier de notificación. En 6 meses, uso de @urgent: 38 mensajes. Mensajes totales: 14,200. Es decir, %0.27 de mensajes son realmente urgentes.
Disciplina de threads: Cada mensaje debe continuar en thread. Solo el mensaje que abre el tema va al canal principal, la discusión sucede en thread. Así al scrollear el canal ves "hay 12 mensajes en este hilo" sin necesidad de leerlos todos. Thread completion rate: %91 — es decir, el mensaje encuentra respuesta en el thread y se cierra, no se derrama al canal principal.
Integración: Cuando se crea un issue en Linear, un thread automático abre en Slack. Cuando el issue cierra, se agrega reacción "✅ Resolved" al thread. Así el lifecycle del issue se puede seguir en Slack pero sin desvincularse de Linear — se preserva la single source of truth. También el resumen IA de reuniones de Granola cae a Slack, pero existe el mismo resumen en Notion — el lector lo puede seguir donde prefiera.
Taxonomía de Canales Slack
En equipo de 12 personas hay 18 canales Slack — pero la taxonomía es clara: #general (empresa), #dev (ingeniería), #growth (marketing/sales), #client-{name} (específico del cliente), #random (off-topic). Cantidad de canales de cliente: 6 — es decir, promedio 2 personas siguen cada cliente. Esta separación mantiene la ratio noise/signal bajo control. En #general hay en promedio 8 mensajes por día — suficiente visibilidad para anuncios críticos, sin spam.
Figma: Component Library y Design Token Sync
Usamos Figma no como mockup tool, sino como fuente del design system. La component library contiene 240 componentes — button, input, card, modal, layout primitive. Cada componente está vinculado a design tokens: color-primary-500, spacing-md, font-body-regular. Estos tokens se sincronizan al código vía Figma API — cuando el designer cambia color-primary-500 en Figma, automáticamente se abre un PR en GitHub, se actualiza la variable CSS.
Este patrón de sync elimina el handoff manual entre design y dev. Cuando el designer marca "ready for dev", un issue automático se abre en Linear, el archivo Figma está incrustado. Cuando el developer abre el issue, tiene el archivo Figma, la spec del componente, los valores de design token — listos. No hay preguntas manuales "¿cuántos pixels es este padding?" — el inspect mode tiene todo incorporado.
El ciclo de design review: cada semana 1 hora de review async — el designer hace preguntas en comentarios de Figma, el developer responde. Sin reuniones en tiempo real. En 6 meses, 24 design reviews, ninguno requirió meeting sync. El review async permite que el developer responda desde su propio flujo de trabajo sin cambio de contexto.
Integración: El archivo Figma se incrusta en Notion — pero con control de versión. Cada revisión de design importante se guarda como branch en Figma, el embed en Notion incluye selector de branch. Así se pueden recuperar revisiones anteriores, se puede rastrear la evolución del design. En los servicios de branding de Roibase, la timeline de evolución de identidad marca del cliente se gestiona con este mismo patrón — cada iteración de logo es un branch Figma, Notion timeline view.
Granola: Transcript de Reunión y Extracción de Action Items
Granola es un asistente IA de reuniones — pero no es herramienta de notas, es motor de extracción de decisiones. Durante la reunión captura transcript en tiempo real, al final genera 3 outputs: (1) resumen estructurado, (2) lista de action items (con owner + due date), (3) decision log (quién decidió qué). Estos 3 outputs se publican automáticamente en Notion.
Datos de 6 meses: 42 reuniones con cliente, 18 syncs internos, total 60 reuniones. Cada reunión promedia 38 minutos, el resumen de Granola toma 4.2 minutos de lectura. Accuracy de extracción de action items: %89 — es decir, de 10 items, 9 salen con owner + due date correcto. El restante %11 requiere corrección manual. Esta accuracy elimina la discusión post-reunión "¿quién iba a hacer qué?".
Integración: Los action items pueden abrirse automáticamente como issues en Linear — pero requieren aprobación manual. Granola ofrece botón "send to Linear", el PM aprueba, se crea el issue. Este paso de aprobación previene que la IA cree action items incorrectos. En 60 reuniones se extrajeron 180 action items, 162 fueron enviados a Linear, %10 fue rechazado (irrelevante o duplicado).
Tool Stack Tradeoff: Integración vs. Propiedad
Usar 5 herramientas (Linear, Notion, Slack, Figma, Granola) es más complejo que una plataforma monolítica única. Pero el tradeoff es claro: la selección de best-of-breed mejoró eficiencia del equipo %34 (tracking de 6 meses: task completion rate pasó de %68 a %91). Hay costo de integración — configurar webhooks, escribir sincronización API, error handling — pero es one-time. La ganancia operacional sucede cada día.
Patrón de propiedad: Cada herramienta tiene 1 responsible owner. Linear → Tech Lead, Notion → PM, Slack → Ops Manager, Figma → Design Lead, Granola → Founder. El owner asegura la adaptación de la herramienta al workflow del equipo, identifica nuevas necesidades de integración, toma decisiones de upgrade. Esta propiedad previene la situación "todos usan pero nadie es responsable".
El umbral para cambiar herramienta se mantiene alto — agregar nueva tool requiere 3 criterios: (1) ¿se integra con el stack actual?, (2) ¿rompe el patrón de single source of truth?, (3) ¿es compatible con cultura async-first?. En 6 meses llegaron 12 propuestas de tool, 2 fueron aceptadas (Granola + 1 tool analytics interno). El resto fue rechazado — porque la combinación del stack existente resolvía los problemas que planteaban.
Impacto Medible del Tool Stack en la Cultura
La selección de herramientas es selección de cultura. Linear enforces sprint discipline, Notion enforces documentation discipline, Slack enforces async discipline — no son features, son patrones culturales que las herramientas refuerzan. En 6 meses el equipo creció (8 a 12 personas) pero las horas de reunión bajaron (12 horas/semana a 6 horas/semana). Esta paradoja es posible gracias al stack async-first.
La disciplina operacional es medible: Linear cycle time P50, Notion doc review latency, Slack async response time, frecuencia de sincronización Figma-to-code, accuracy de Granola action items. Estas métricas se discuten en reviews trimestrales a nivel de founder/lead. La herramienta no es solo instrumento — es la superficie medible de la performance del equipo. Ahora: testea el patrón de single source of truth en tu propio stack, establece forcing functions para disciplina async-first, recolecta métricas. La productividad no es shortcut, es diseño sistemático.