Herramientas y tech stack del gerente de ingeniería: la guía de compra honesta de 2026

Tomó el equipo hace seis semanas. Ahora ha tenido tiempo de mirar realmente el "tech stack" y el panorama no es bonito. El gestor de proyectos es un tablero de Jira en el que nadie confía porque hace tres sprints alguien editó masivamente 200 tickets y rompió las prioridades. Slack tiene 47 canales, la mitad archivados pero no del todo. Notion es un cementerio de runbooks a medias escritos, editados por última vez por un ingeniero que se fue en 2024. Hay un Google Doc llamado "Objetivos_FINAL_v3" al que todos hacen referencia y nadie puede encontrar. El gerente de ingeniería anterior se fue, y el contexto también.

¿Le suena familiar? Debería. Esto es lo que hereda cada nuevo gerente de ingeniería, y el impulso de "arreglar el stack" comprando una herramienta brillante más es exactamente cómo llegó a estar así de mal.

Esta guía es lo opuesto a eso. Es una guía de compra que mayormente le dice qué recortar, qué consolidar y cuáles son las seis categorías que realmente importan. Precios reales, compromisos reales y un plan de 30 días que puede poner en marcha el lunes.

Por qué la mayoría de los stacks de gerente de ingeniería están rotos

El stack que heredó no fue diseñado. Fue acumulado. Tres managers distintos eligieron herramientas una a la vez durante tres años, cada uno resolviendo el problema que tenía delante, ninguno pensando en el conjunto. Nadie es dueño del stack ahora. El equipo usa aproximadamente el 30% de lo que paga. Los bugs de clientes viven en tres lugares (herramienta de soporte, mensaje directo de Slack al ingeniero y una nota personal de Apple en el portátil de alguien). Las notas de 1:1 están dispersas en documentos personales. ¿Fechas de renovación? Desconocidas. La renovación automática anual se disparará y se enterará de un cargo de $14,000 después del hecho.

La solución no son más herramientas. Es decidir qué trabajo se supone que debe hacer cada herramienta, elegir una herramienta por trabajo y deshacerse del resto. Seis categorías lo cubren. Ese es el marco completo.

Las 6 categorías principales: lo que realmente necesita un stack de gerente de ingeniería

Olvide las listas de herramientas. Piense en trabajos por realizar. Hay seis cosas que su stack debe manejar. Elija una herramienta por categoría. Si tiene dos, ese es el duplicado que está causando sus mensajes de Slack "¿dónde encuentro eso?".

1. Gestión de proyectos: dónde vive el trabajo

Este es en el que nadie confía, lo cual es el que rompe todo lo demás.

• Linear ($10/usuario/mes Standard, $14 Plus) es rápido, con opinión propia y construido para equipos de ingeniería de producto de menos de 50 personas. Ciclos en lugar de sprints, atajos de teclado que funcionan y un flujo de trabajo con opinión propia que resiste ser moldeado en un clon de Jira. Es la opción predeterminada si su equipo entrega software y le gusta entregarlo.
• Jira Cloud Standard ($7.75/usuario/mes) hasta Premium ($15.25/usuario/mes) es la opción segura para organizaciones que necesitan cumplimiento, esquemas de permisos complejos o integración con el resto del mundo de Atlassian. También es la herramienta que su equipo odiará silenciosamente si son un equipo de producto de 12 personas que no necesita nada de eso.
• Shortcut (aproximadamente $8.50/usuario/mes) es la alternativa más ligera (anteriormente Clubhouse), menos rígida que Jira, menos con opinión propia que Linear. Está bien si Linear parece demasiado de startup y Jira parece demasiado empresarial.

La trampa: elegir Jira "porque la empresa ya lo tiene". Si su equipo odia la herramienta, la calidad de sus datos es basura, sus revisiones de sprint se convierten en teatro y vuelve a la verdad en Slack. Invierta el capital político para cambiar, o acepte que la higiene de Jira ahora es una parte real de su trabajo.

Regla de decisión: menos de 50 ingenieros entregando producto, opte por Linear. Más de 50 con necesidades de auditoría y cumplimiento, Jira Premium. En cualquier punto intermedio, haga pasar al equipo por una prueba de una semana y deje que los ingenieros voten.

2. Código y revisión: donde los ingenieros viven todo el día

Este está mayormente resuelto, razón por la que seré breve.

• GitHub Team ($4/usuario/mes) es el mínimo. GitHub Enterprise Cloud ($21/usuario/mes) le da SAML/SSO, registros de auditoría y las cosas que su equipo de seguridad eventualmente exigirá.
• GitLab Premium ($29/usuario/mes) gana exactamente un escenario: realmente quiere una herramienta para repositorio, CI y análisis de seguridad, y está dispuesto a pagar la prima y aceptar una UX de revisión ligeramente más torpe a cambio de menos proveedores.
• Bitbucket es la respuesta correcta solo si ya está muy metido en Atlassian y su equipo escribe más YAML que Markdown.

La opinión honesta: GitHub es el predeterminado por una razón. Los efectos de red son reales (cada contratista y nuevo empleado ya tiene una cuenta, cada dependencia de código abierto está ahí), y la UX de revisión sigue siendo la mejor de la categoría. Si alguien en su equipo está promoviendo un cambio a GitLab, pregúntele qué problema específico está resolviendo. "Una sola herramienta" no es un problema. Es una preferencia.

Si está contratando a un Staff Engineer para que sea dueño de la infraestructura, esa es la persona que debería impulsar cualquier decisión a nivel de plataforma aquí. Consulte la descripción del puesto de Staff Software Engineer para saber qué buscar.

3. Incidentes y on-call: el problema de las 3 de la madrugada

Esta es la categoría donde ser barato le cuesta más.

• PagerDuty Professional ($21/usuario/mes) es el veterano. Integraciones maduras, alertas fiables, las herramientas de rotación con las que otros proveedores todavía están poniéndose al día.
• Opsgenie Standard ($9/usuario/mes) es la alternativa de Atlassian. Más barato, adecuado para equipos más pequeños y obviamente el camino de menor resistencia si ya está pagando a Atlassian.
• Incident.io ($16 a $24/usuario/mes según el nivel) es el nuevo competidor de crecimiento rápido. Nativo de Slack, increíblemente rápido de configurar y el flujo de trabajo de postmortem y comunicación de incidentes es el mejor de la categoría. Si su equipo vive en Slack, este es el que debe evaluar primero.

La trampa: poner la rotación en una hoja de cálculo de Google "por ahora". Lo alertarán a las 3 de la madrugada, la rotación habrá fallado silenciosamente hace seis semanas cuando alguien se fue de vacaciones, y pasará la interrupción averiguando quién está on-call en lugar de arreglar el problema. Pague los $21 por asiento. Es el seguro más barato que comprará jamás.

Regla de decisión: menos de 8 ingenieros en rotación y cultura nativa de Slack, Incident.io. Equipo más grande o ya en Atlassian, Opsgenie. Compromisos de fiabilidad regulados o atención al cliente 24/7, PagerDuty.

4. Desempeño, 1:1s y retroalimentación: donde la mayoría de los gerentes de ingeniería gastan de más

Sea honesto sobre lo que realmente necesita aquí.

• Lattice (aproximadamente $11/usuario/mes para el paquete de Gestión del Talento, más para el paquete HRIS completo) es la opción refinada. Objetivos, evaluaciones, 1:1s, retroalimentación, todo en uno. Vale la pena si tiene más de 30 ingenieros y RR. HH. está comprometido.
• 15Five ($10 a $16/usuario/mes según el paquete) es la alternativa ligeramente más orientada a la gestión del desempeño. Fuerte en check-ins semanales y OKR.
• Officevibe ($5/usuario/mes) hace bien las encuestas de pulso y poco más.

La opinión honesta: si tiene menos de 30 ingenieros, no necesita nada de esto. Una plantilla de Notion compartida para las notas de 1:1, un formulario de revisión trimestral en Google Forms y un recordatorio de calendario le dan el 80% del valor al 0% del costo. El 20% restante son mayormente los dashboards que su VP quiere, y su VP probablemente no los mira en realidad.

La trampa es comprar Lattice para "mejorar nuestra cultura de retroalimentación". Lattice no hace que la gente dé retroalimentación honesta. Usted modelándola en sus 1:1 sí lo hace. Las herramientas amplifican la cultura; no la crean. Si su cadencia de 1:1 está rota, arregle su cadencia de 1:1 antes de comprar cualquier cosa.

5. Documentación y runbooks: elija uno. Solo uno.

• Notion ($10/usuario/mes Plus, $15 Business) es el favorito del equipo para el conocimiento interno. Flexible, rápido para escribir, modelo de bloques que los ingenieros captan rápidamente.
• Confluence ($6.05/usuario/mes Standard, $11.55 Premium) es el predeterminado empresarial. Mejores controles de acceso, integración nativa con Jira, menos agradable para escribir.
• GitBook es bueno para la documentación de ingeniería pública (documentación para desarrolladores de una API externa, por ejemplo) pero es excesivo para runbooks internos.

La trampa: usar Notion Y Confluence. Esta es la fuente más grande de mensajes de Slack "¿dónde está el runbook?" que veo en los stacks de gerente de ingeniería. Elija uno. Si su empresa tiene una licencia de Confluence y no puede escapar de ella, ponga los runbooks ahí y use Notion solo para borradores personales. Si puede elegir libremente, Notion para un equipo de producto, Confluence si tiene que interoperar con PMs y finanzas que ya viven en Atlassian.

6. CRM y el bucle de retroalimentación de bugs de clientes: la categoría que la mayoría de los stacks ignora

La mayoría de los artículos sobre tech stack de gerente de ingeniería se detienen en cinco categorías. Esta es la brecha.

Si su equipo entrega software para clientes B2B de pago, los bugs de clientes llegan con nombre: "Acme Corp dice que el botón de exportación está roto". Sin un CRM en el bucle, esos bugs mueren en mensajes directos al soporte, se vuelven a escribir en Jira sin contexto de cuenta y sus ingenieros los corrigen a ciegas. El equipo de soporte no puede decirle al cliente cuándo está arreglado porque la conexión entre el ticket y el trabajo de ingeniería es la memoria de alguien.

Rework ($12/usuario/mes para CRM/Sales Ops, $6/usuario/mes para Work Ops; consulte rework.com/pricing) cierra este bucle. Los tickets de soporte, las cuentas de clientes y las tareas de ingeniería viven en el mismo espacio de trabajo, así que cuando un ingeniero corrige un bug puede ver qué cuentas lo reportaron y el equipo de soporte recibe una notificación automáticamente. Es la única herramienta de la categoría 6 que nombraría en una guía dirigida a gerentes de ingeniería, porque la alternativa (unir Zendesk más Jira más Salesforce usted mismo con Zapier y oraciones) cuesta más de $12/usuario/mes en tiempo de ingeniería perdido la primera vez que una escalada de cliente P1 llega un viernes por la tarde.

Encuadre honesto: si su equipo solo entrega herramientas internas, no necesita esta categoría en absoluto. Omítala. Si entrega a clientes de pago y los bugs se reportan por nombre de empresa, necesita una respuesta aquí, y la pregunta es solo si la construye (Zendesk + Jira + Salesforce + pegamento de integración) o la compra (Rework, en un solo espacio de trabajo).

La auditoría de stack de 30 días

Este es el entregable real de esta guía. Reserve cuatro semanas. Haga una cosa por semana. No intente hacerlo todo en una sola tarde. No obtendrá respuestas honestas.

Semana 1: inventario

Abra una hoja de cálculo. Una fila por herramienta. Columnas:

Rellénela para cada herramienta de pago que toca el equipo. Obtenga los recuentos de asientos de cada panel de administración. El porcentaje de usuarios activos importa más que el recuento de asientos. La mayoría de los gerentes de ingeniería encuentran al menos 2 a 3 suscripciones zombis en la primera semana (las herramientas de "las probamos hace 18 meses y nunca cancelamos"). Las fechas de renovación vienen de facturación o del equipo de compras. Si nadie conoce la fecha de renovación, eso es un hallazgo.

Espere que esto tome unas 4 horas. Se sentirá como trabajo improductivo. Hágalo de todos modos.

Semana 2: mapear a las 6 categorías principales

Revise su inventario y etiquete cada herramienta con una de las seis categorías. Los duplicados saltan a la vista: Notion Y Confluence, Linear Y Jira, mensajes directos de Slack Y un sistema real de tickets, tres herramientas de retroalimentación diferentes, una plataforma de "métricas de ingeniería" que se superpone con lo que ya hace su gestor de proyectos. Marque cada duplicado.

Cualquier cosa que no encaje en las seis categorías también es un hallazgo. Puede ser una séptima cosa real que su equipo necesita (CI/CD que no viene incluido con su plataforma de código, por ejemplo, o una herramienta de feature flag). Puede ser una herramienta que resuelve un problema que ya no tiene.

Semana 3: hablar con el equipo

En su próxima ronda de 1:1s, haga una pregunta: "¿Qué herramienta evitas usar y qué usas en su lugar?"

El stack en la sombra le dice qué está realmente roto. Si tres ingenieros le dicen que evitan Jira y usan un espacio de trabajo privado de Linear, eso no es autonomía, eso es fragmentación de datos, y está pagando por ambos. Si dos ingenieros le dicen que evitan el Notion de la empresa porque la búsqueda está rota y guardan notas en Obsidian, la respuesta es arreglar Notion, no agregar Obsidian al stack.

Un guion corto que funciona:

"Estoy haciendo una auditoría del stack. Sin juicios, sin chivatos. ¿Qué herramienta evitas usar y dónde haces realmente ese trabajo? Quiero saber cuál es la brecha entre lo que pagamos y lo que realmente usas."

Obtendrá respuestas más honestas de las que espera. A los ingenieros les encanta decirle qué está roto si confían en que usted hará algo al respecto.

Semana 4: decidir y consolidar

Elija una herramienta por categoría. Configure recordatorios de renovación en el calendario 60 días antes de cada renovación para tener tiempo de evaluar, no solo de pagar automáticamente. Cancele los duplicados. Escriba un documento de una página "Este es nuestro stack" con las seis categorías, la herramienta elegida para cada una, quién es dueño de la renovación y cuál es el trabajo por realizar. Fíjelo. Referencíelo en la incorporación.

Esta también es la semana para enviar los correos de cancelación. No lo demore. Los proveedores le ofrecerán un descuento para quedarse; eso es una razón para irse, no para quedarse.

Errores comunes

Una lista corta de los errores que veo más:

• Comprar herramientas para solucionar problemas de cultura. Lattice no hará que su equipo dé retroalimentación honesta. Una plantilla de documento de 1:1 no lo convertirá en un mejor oyente. Las herramientas amplifican la cultura; no la crean.
• Dejar que cada ingeniero elija sus propias herramientas "por autonomía". Autonomía en librerías y editores, sí. Autonomía en el gestor de proyectos, no. El costo de un stack fragmentado recae sobre el próximo gerente de ingeniería, el nuevo empleado y la rotación on-call.
• Renovar anualmente sin auditar el uso. Pagará por 12 asientos cuando tenga 7 ingenieros. La renovación automática es el predeterminado por una razón: están apostando a que usted no verificará. Verifique.
• Elegir la herramienta más barata en cada categoría. A veces el PagerDuty de $21/asiento vale la pena porque la alternativa de $9/asiento pierde una alerta. El costo de una alerta perdida no es "$12/asiento ahorrado por mes".
• Darle demasiada importancia a las integraciones. Si necesita un grafo de Zapier con 14 zaps para hacer funcionar su stack, su stack está mal. Elija herramientas que sean buenas por sí solas y se integren de forma nativa con las demás que ha elegido.

Plantillas y herramientas

Tres artefactos que vale la pena guardar en la carpeta de runbooks del equipo:

1. Hoja de cálculo de auditoría de stack (la tabla de la Semana 1). Ejecútela trimestralmente.
2. Documento de una página "Nuestro stack de ingeniería": las seis categorías, la herramienta elegida para cada una, el costo por asiento, el trabajo por realizar, la fecha de renovación, el dueño. Fíjelo en su herramienta de documentación.
3. Guion del stack en la sombra en 1:1 (la pregunta de la Semana 3). Agréguelo a su banco de preguntas de 1:1 rotativo para hacerla cada seis meses.

Cómo medir el éxito

Dentro de los 90 días de ejecutar esta auditoría, esto es lo que es cierto:

• Puede nombrar cada herramienta, su costo por asiento, su dueño y el trabajo por realizar que sirve, de memoria.
• Las fechas de renovación están en un calendario compartido con recordatorios de 60 días de anticipación.
• Cada una de las seis categorías tiene exactamente una herramienta. El stack en la sombra se ha reducido.
• Los bugs de clientes (si entrega a clientes) tienen una sola ruta de entrada.
• Un nuevo empleado puede incorporarse al stack completo en menos de un día.

Si incluso tres de esos cinco son ciertos, está por delante del 90% de los gerentes de ingeniería con los que hablo. Las herramientas no son el trabajo. El trabajo es entregar software con un equipo que confía en usted. El stack solo se quita del camino.

Aprenda más

• Cadencia de 1:1 del gerente de ingeniería
• Planificación de sprint para equipos de ingeniería pequeños
• Cómo contratar a su primer Staff Engineer
• Incorporación del gerente de ingeniería