La fatiga de herramientas es real: qué hacer al respecto
Los Engineering Managers manejan demasiadas herramientas. Así funciona la fatiga de herramientas, qué cuesta y qué soluciones sistémicas realmente ayudan.
By Ellis Keane · 2026-03-31
Son las 9:47 de un martes por la mañana y la Engineering Manager no ha escrito una línea de código, no ha revisado un solo pull request ni ha tenido una conversación con nadie del equipo sobre trabajo de ingeniería real. Ha estado actualizando un documento de Notion con el estado de Linear, cruzando referencias en un hilo de Slack para averiguar si se tomó una decisión o simplemente se discutió, e intentando recordar si el comentario de Figma que vio ayer estaba en el mockup v2 o en el v3, porque la notificación no incluía suficiente contexto para saberlo.
Si eres Engineering Manager, probablemente reconoces esta mañana aunque nunca la hayas llamado fatiga de herramientas.
La forma del problema
La fatiga de herramientas para los Engineering Managers no se trata realmente de tener demasiadas herramientas (aunque así es como suele plantearse). Se trata de la carga cognitiva de mantener un modelo mental de dónde vive la información, quién la puso ahí y si sigue siendo actual. Cada herramienta del stack es una fuente de verdad separada, y el trabajo del Engineering Manager se ha convertido silenciosamente en coser esas fuentes en algo suficientemente coherente para tomar decisiones.
Así es como se ve esto en la práctica. Digamos que gestionas un equipo de seis ingenieros y tu empresa usa Linear para el seguimiento de proyectos, GitHub para el código, Slack para la comunicación, Figma para el diseño y Notion para la documentación. Son cinco herramientas, lo cual es francamente conservador para la mayoría de las startups con las que hablamos.
title: "El martes por la mañana de una Engineering Manager" 8:30 AM|ok|Abre Linear, escanea el sprint activo. Tres issues marcados como «en progreso» sin actualizaciones recientes. 8:42 AM|amber|Cambia a GitHub para comprobar si existen PRs para esos issues. Dos sí existen. Uno no. 8:51 AM|ok|Revisa Slack para obtener contexto sobre el PR que falta. Encuentra un hilo del viernes donde el ingeniero mencionó un bloqueo. 9:03 AM|amber|El bloqueo hace referencia a un comentario de Figma. Abre Figma. Desplaza los hilos de comentarios en el archivo de diseño. 9:14 AM|missed|Encuentra el comentario, pero fue resuelto sin actualizar el issue de Linear. Es posible que el ingeniero no sepa que el bloqueo fue eliminado. 9:22 AM|amber|Le envía un mensaje directo al ingeniero en Slack para comprobarlo. Espera respuesta. 9:31 AM|ok|Actualiza el documento de estado en Notion con lo aprendido hasta ahora. Tres párrafos, principalmente sobre lo que todavía no sabe. 9:47 AM|missed|Se da cuenta de que no ha hecho ningún trabajo de gestión real. Solo arqueología de información.
En algún punto del camino, el título «Engineering Manager» se convirtió en un sinónimo educado de «Router API Humano» – alguien cuya función principal es transportar contexto entre sistemas que se niegan a comunicarse entre sí.
Esa no es una mañana excepcional. Es la línea base. La fatiga de herramientas para los Engineering Managers significa que la tarea de entender qué ocurre en el equipo se ha convertido silenciosamente en un ejercicio de integración de datos a tiempo completo, y nadie lo planeó así.
stat: "77 minutos" headline: "Tiempo diario promedio dedicado a ensamblar contexto" source: "Basado en el seguimiento de tiempo interno de nuestro equipo durante 4 semanas"
Por qué empeora, no mejora
La fatiga de herramientas se agrava – y lo digo como alguien que lo ha visto ocurrir en nuestro propio equipo. Cada nueva herramienta que añades no solo suma su propio overhead: multiplica las conexiones que necesitas mantener entre las herramientas existentes.
Con 5 herramientas, tienes 10 posibles conexiones por pares. Con 8, tienes 28. Con 12, tienes 66. El Engineering Manager no necesita usar activamente todas esas conexiones, pero sí necesita saber cuáles existen y cuáles están rotas, porque una conexión rota es donde se pierde la información.
Y la pérdida de información en la gestión de ingeniería no es abstracta. Es un diseñador que no sabía que su bloqueo había sido resuelto, así que esperó dos días antes de comenzar la siguiente iteración. Es un compromiso de sprint que asumió que una dependencia estaba completada porque el estado de Linear decía «completo», pero el PR real todavía estaba en revisión. Es la reunión de sincronización semanal donde los primeros quince minutos se gastan estableciendo lo que todos ya sabían individualmente pero no habían compartido, porque las herramientas no conectaron esas señales.
La fatiga de herramientas no tiene que ver con el número de herramientas. Tiene que ver con el número de espacios entre ellas y el hecho de que cerrar esos espacios se ha convertido en el segundo trabajo no oficial del Engineering Manager.
Lo que no funciona
Tres respuestas habituales a la fatiga de herramientas que en realidad no funcionan:
Consolidación por sí misma. El instinto es comprensible: si el problema son demasiadas herramientas, usa menos herramientas. Pero los equipos de ingeniería tienen opiniones fuertes sobre sus herramientas por buenas razones. Intenta reemplazar Linear con «el módulo de gestión de proyectos dentro de [plataforma todo-en-uno X]» y observa la revuelta. Las herramientas no son el problema; los espacios entre ellas sí lo son. Cambiar un conjunto de herramientas por otro simplemente mueve los espacios.
Dashboards. Lo sé, lo sé. El atractivo de «un dashboard para gobernarlos a todos» es casi irresistible, y cada empresa de SaaS empresarial tiene una presentación al respecto. Pero la mayoría de los dashboards que hemos probado son instantáneas de solo lectura del estado – te muestran dónde están las cosas, pero no qué cambió desde ayer, por qué cambió o qué deberías hacer al respecto. Un Engineering Manager que mira un dashboard todavía tiene que ir a cada herramienta para obtener el contexto real detrás de los números.
Más reuniones. Esta es la que más duele porque es muy común. Cuando las herramientas no se comunican entre sí, los equipos compensan con comunicación síncrona (standups diarios, sincronizaciones semanales, check-ins ad hoc). La reunión no resuelve el problema – tapa un flujo de trabajo roto con ancho de banda humano. Y el ancho de banda humano es el recurso más caro del equipo.
Lo que se intenta
- Consolidación de herramientas – reemplazar 5 herramientas con 1. Los ingenieros se rebelan; el todo-en-uno hace 5 cosas mediocrement.
- Dashboards – instantáneas de solo lectura que igualmente requieren contexto de las herramientas originales.
- Más reuniones – transferencia de información síncrona para compensar el flujo de trabajo asíncrono roto.
Lo que realmente ayuda
- Conexión, no consolidación – mantener las herramientas, cerrar los espacios entre ellas.
- Enrutamiento de señales – mostrar qué cambió y qué necesita atención, no todo.
- Entrega de contexto asíncrono – la información llega donde y cuando la necesitas, sin tener que pedirla.
Lo que realmente ayuda
Los fixes que sobreviven el contacto con un equipo de ingeniería real tienden a compartir un rasgo común: no piden a los humanos que hagan el trabajo de integración. Construyen las conexiones a nivel de sistema y dejan que el Engineering Manager pase su tiempo en decisiones de criterio en lugar de en la recopilación de información.
Enrutamiento intencional de notificaciones. La mayor parte de la fatiga de herramientas proviene de que la información equivocada llega al lugar equivocado. Canales de Slack que mezclan actualizaciones de estado con comentarios de diseño. Notificaciones de GitHub para repositorios en los que no trabajas activamente. El fix no son menos notificaciones, sino mejor enrutadas. Establece convenciones de canales (usamos #proj-[nombre]-eng para señales de ingeniería, #proj-[nombre]-design para diseño) y poda agresivamente. Una automatización concreta que se paga sola de inmediato: configura un webhook de GitHub que publique los cambios de estado de PR en el canal de Slack del proyecto con el ID del issue de Linear en el mensaje. Eso solo elimina la comprobación de «¿existe un PR para este issue?» del ritual matutino. No es trabajo glamuroso, pero reduce el ruido de manera significativa.
Un presupuesto semanal para «arqueología de información». Acepta que algo de ensamblaje entre herramientas es inevitable por ahora, y ponle un límite de tiempo. Asignamos treinta minutos el lunes por la mañana específicamente para el escaneo de «qué pasó en las herramientas desde el viernes». Tenerlo programado significa que no se filtra en cada otra hora de la semana, y el límite de tiempo significa que paras cuando se acaba el tiempo en lugar de caer en el agujero del conejo.
Enrutamiento de señales entre herramientas. Hacia aquí se dirige la categoría – y sí, esto es lo que estamos construyendo en Sugarbug. En lugar de que el Engineering Manager compruebe manualmente Linear, luego GitHub, luego Slack, luego Figma para construir el estado del mundo: una capa que se conecta a todas esas herramientas a través de sus APIs y te enruta los cambios, decisiones y bloqueos relevantes. No un dashboard – que es pasivo –, sino algo que te dice activamente qué necesita tu atención y por qué. Se parece más a cómo un líder de equipo experimentado te haría un briefing si ese líder de equipo hubiera leído cada hilo de Slack y cada comentario de PR desde ayer.
La versión honesta de dónde estamos: los primeros dos fixes funcionan hoy, y el tercero es hacia lo que Sugarbug está trabajando. Todavía no hemos terminado – no hemos decidido exactamente qué tan agresivo debe ser el filtrado de señales, y el modelo de ranking todavía muestra algo de ruido que preferiríamos suprimir. Pero la arquitectura central funciona: conectores de API para cada herramienta, clasificación de señales basada en LLM y un grafo de conocimiento que vincula personas, tareas y debates entre fuentes. Maneja el escaneo de «qué pasó desde el viernes» en segundos en lugar de setenta y siete minutos, que es la parte que nos mantiene en marcha.
El trabajo de un Engineering Manager no debería ser coser cinco herramientas en una imagen coherente. Ese es el trabajo de una máquina. El trabajo del ser humano es decidir qué hacer con la imagen. attribution: Ellis Keane
Preguntas frecuentes
Recibe la inteligencia de señales directamente en tu bandeja de entrada.
Q: ¿Qué es la fatiga de herramientas para los Engineering Managers? A: La fatiga de herramientas es el coste cognitivo y operativo de gestionar el trabajo en demasiadas herramientas SaaS desconectadas. Para los Engineering Managers, significa pasar más tiempo moviendo información entre Linear, Slack, GitHub, Figma y Notion que tomando decisiones con esa información.
Q: ¿Ayuda Sugarbug con la fatiga de herramientas? A: Sí – se conecta a tus herramientas existentes mediante integraciones nativas de API, clasifica las señales de cada una y muestra lo que importa en un solo lugar. En lugar de revisar cinco dashboards antes de tu primer café, recibes el contexto que necesitas directamente. Todavía estamos iterando en cómo funciona exactamente el filtrado de señales (honestamente, es uno de los problemas de diseño más difíciles que hemos abordado), pero el pipeline central está activo.
Q: ¿Cuántas herramientas usa un equipo de ingeniería típico? A: La mayoría de los equipos con los que hablamos usan entre 8 y 14 herramientas SaaS según el tamaño y la función del equipo. El problema no es el número en sí, sino cuánto contexto se pierde en los espacios entre ellas. Hemos visto equipos de tres personas con ocho herramientas y equipos de cincuenta personas con nueve. El número importa menos que si las herramientas realmente comparten información.
Q: ¿Deberían los Engineering Managers consolidar su stack de herramientas? A: A veces, pero normalmente es el enfoque equivocado. Reemplazar cinco herramientas de propósito específico con un todo-en-uno que hace cinco cosas mediocremente no soluciona el problema subyacente. La solución real es conectar las herramientas que ya tienes para que la información fluya entre ellas sin que alguien tenga que copiar y pegar contexto manualmente. Si puedes reducir redundancia genuina – dos rastreadores de proyectos, por ejemplo –, hazlo. Pero no consolides por el simple hecho de tener un número menor.