El síndrome del objeto brillante está desperdiciando el tiempo y la energía de tu equipo. Aquí te explicamos qué hacer.

“Fue una distracción que podría haber descarrilado fácilmente el progreso en las prioridades existentes si no hubiéramos frenado a tiempo,” recuerda Anand Sainath, jefe de ingeniería y cofundador de 100x, quien decidió detener la integración.

Sin embargo, otros no han tenido tanta suerte. Para muchos equipos, la búsqueda de la “próxima gran cosa” poco a poco secuestró la hoja de ruta del producto. Lo que quedó fue un mosaico de herramientas a medio terminar y prioridades perdidas; algo a lo que Sainath se refiere como el costo silencioso del síndrome del objeto brillante.

¿Qué es realmente el síndrome del objeto brillante?

El síndrome del objeto brillante (SOS, por sus siglas en inglés) ocurre cuando los equipos se desvían por nuevas herramientas, marcos de trabajo o tecnologías, a menudo a expensas de las prioridades existentes. 

“Cuando aparece una nueva tecnología, como ocurre ahora con la IA, el mercado se entusiasma con sus aplicaciones. Puede haber presión para girar hacia la tendencia y mantenerse por delante de la competencia,” dice Raju Malhotra, CPTO en Certinia.

Es entonces cuando la herramienta o el marco de trabajo “brillante” comienza a infiltrarse en tus planes y “aleja la ingeniería del trabajo que realmente importa hoy a los clientes.” 

La historia de Evernote marca todas las casillas del síndrome del objeto brillante. Tenía todos los ingredientes adecuados: usuarios fieles, un producto sólido y un nicho claro. En vez de reforzar sus funciones principales, la empresa se diversificó hacia productos físicos y lanzó funciones poco desarrolladas como Work Chat. 

El producto se volvió pesado, el rendimiento disminuyó y los usuarios se cambiaron a herramientas más sencillas como Notion y Google Keep. En 2022, Evernote fue adquirida y, a principios de 2023, la mayoría de su personal fue despedido. 

El SOS no siempre termina en bancarrota o despidos, pero casi siempre descarrila el impulso, haciendo que: 

• Demora en las entregas de proyectos: Cambios frecuentes hacia nuevas tecnologías a mitad de proyecto pueden desorganizar la planificación, interrumpir los ciclos de ejecución e introducir un alcance inflado y no planificado. Eso fue exactamente lo que ocurrió con el proyecto Virtual Case File del FBI. Tras cinco años y 170 millones de dólares invertidos, el proyecto se abandonó, en parte porque el cambio constante entre la burocracia y el negocio rompía el ritmo de entrega.
• Incremento de los costos de ingeniería: Sin un marco para evaluar nuevas tecnologías, las decisiones motivadas por el objeto brillante suelen provocar una saturación de herramientas, deuda técnica y altos costos de desarrollo de software. Los equipos incluso invierten tiempo en prototipos que nunca se implementan o, peor aún, que se despliegan y luego se reescriben.
• Reducción de la productividad de los desarrolladores: Cada nueva herramienta implica una curva de aprendizaje más, más errores y más “pruebas rápidas” que rara vez resultan serlo. Dispersa a los ingenieros, reduce la productividad hasta en un 40% y genera fatiga y reacción constante ante problemas, energía que podría haberse invertido en funciones clave del producto.
• Desgaste de la confianza de los interesados: El SOS también envía una señal equivocada a los líderes del negocio. Si las prioridades cambian demasiado seguido y los plazos se incumplen, la alta dirección puede empezar a dudar de la capacidad de ingeniería para entregar. Una vez que se pierde la confianza, es difícil recuperarla.

Evita el arrepentimiento por el objeto brillante: 3 preguntas clave para tu equipo

Ya conoces el caos que el síndrome del objeto brillante puede causar en tu equipo. Entonces, ¿cómo determinar si esa nueva librería, SDK o servicio vale la pena—antes de que consuma tiempo y enfoque? Nuestros expertos recomiendan algunos filtros:

1. ¿Es un "Wrapper" o solo un "parche"?

El filtro de Sainath al tratar con herramientas o tecnologías nuevas y atractivas es sencillo: ¿Esto resuelve algo importante a largo plazo o es simplemente un parche?

“Un parche solo tapa casos aislados menores o cubre limitaciones temporales. Pero lo más probable es que la próxima versión del modelo solucione eso de todos modos. Así, lo que has construido queda desactualizado al instante.” 

Le interesa más construir wrappers: capas limpias sobre modelos fundamentales que aporten utilidad real a través de diseño, flujos de trabajo o contexto.

“El término LLM wrapper se usó casi de forma despectiva al principio, pero fundamentalmente, muchos productos valiosos se construyen sobre tecnología subyacente,” comenta Sainath. “Mira Cursor. Uno podría decir que es solo un wrapper, pero aporta un valor significativo y enfocado.”

Desde su punto de vista, los parches son distracciones que fácilmente pueden convertirse en objetos brillantes. Los wrappers bien concebidos, en cambio, pueden convertirse en productos centrales.

2. ¿Qué Elegimos No Construir?

Según Malhotra, hacer un seguimiento de lo que el equipo decide no construir es tan importante como lo que sí se incluye en la hoja de ruta. “Eso nos evita perseguir funciones que pueden lucir bien en una demostración pero que en realidad no mejoran el trabajo diario,” dice.

Incluso cuando el equipo no está seguro de que algo esté listo para un despliegue más amplio, lo prueban con usuarios pioneros. “Eso nos da retroalimentación sin alterar la hoja de ruta.”

3. ¿Cuál es el Valor para el Negocio? 

Para el vicepresidente de ingeniería de Customer.io, Paul Senechko, entender el valor empresarial detrás de los esfuerzos de ingeniería es el primer y más crítico filtro. Si una nueva herramienta o sistema no aporta valor a ninguno de los dos, dice, probablemente no es el momento adecuado para implementarlo.

“El principio de liderazgo de nuestra compañía es que somos expertos en nuestros clientes,” explica Senechko. “Usamos este principio para guiar nuestra inversión en tecnología y asegurarnos de construir siempre pensando en el cliente y el negocio.”

Para mantener a su equipo enfocado, Senechko se apoya en unas pocas preguntas simples pero poderosas: ¿Cuánto nos cuesta esto en tiempo y recursos? ¿Mejora nuestro producto? ¿Ayudará a que nuestros clientes tengan más éxito?

Sainath añade su propio enfoque, con lo que él llama las preguntas del “qué pasaría si”: “¿Qué pasa si la tecnología subyacente mejora 10 veces? ¿Nuestro producto mejora inherentemente o de repente se vuelve irrelevante?”

También indaga sobre el esfuerzo necesario para concretar esas mejoras: “¿Nos beneficiaremos automáticamente de estos avances, o requerirá una re-arquitectura importante para ponernos al día?”

Analizar estos escenarios con tu equipo puede ayudarte a decidir si priorizar esa nueva pila tecnológica brillante o quedarte con lo que ya funciona.

Blindando tu Hoja de Ruta contra el SOS (Sin Matar la Innovación) 

Cuando surge tecnología nueva y emocionante, hay que tomarla con cautela y equilibrar la innovación con el progreso real.

Así es como los CTOs manejan el miedo a quedarse atrás (FOMO) y mantienen a sus equipos enfocados y con los pies en la tierra:

1. Define Criterios de Salida para los Proyectos Antes de Comenzar

Muchas pruebas "exploratorias" de tecnología se convierten en iniciativas paralelas de larga duración, con alcance creciente y deuda técnica recurrente, principalmente porque nadie define cómo o cuándo terminan. Si no hay responsable, ni cronograma, ni criterios de éxito, es solo cuestión de tiempo para que el Síndrome del Objeto Brillante entierre todo el esfuerzo. Para evitarlo, trata cada prueba tecnológica como una característica de producto: acotada, limitada en el tiempo, con responsable y orientada por un caso de uso real. 

Como dice Senechko: “Aplicamos a casos de uso pequeños pero reales, y partimos desde ahí. Una vez que decidimos experimentar con nuevas tendencias, nos aseguramos de identificar un área pequeña o bien delimitada donde podemos probar y verificar si esto funciona. Así, podemos experimentar y adquirir experiencia real con la tecnología antes de hacer una gran apuesta.”

Incluye un evaluador transversal (EM + PM + ingeniero senior) para una valoración objetiva y crea una cronología estructurada que incluya:

• Duración máxima: Límite de 2 sprints (+1 de margen) para mantenerlo ágil y evaluable
• Hitos Go/No-Go con condiciones de salida: Define un momento de revisión explícito donde el equipo decide continuar, iterar o detenerse (más del 10% de los builds fallaron, o falta de integración con la herramienta de CI/CD). 

Senechko incluso sugiere que los equipos experimenten con iniciativas de tiempo fijo y alcance variable, en las que su equipo establece de antemano el “apetito” de cuánto tiempo están dispuestos a invertir y buscan entregar el mejor resultado posible dentro de ese margen. “Esto nos ha permitido innovar y fallar rápidamente cuando esas nuevas direcciones no parecen ir en la dirección correcta.”

2. Usa Métricas para Medir el Éxito

Una vez que se comprenda la viabilidad técnica y el esfuerzo de ingeniería, define cómo se verá el éxito. Esa es la línea que separa un despliegue disciplinado de un proyecto caótico con alcance desbordado. Crea un marco que mida el éxito a través de múltiples dimensiones:

• Personas: Aumento de la productividad de los desarrolladores, incremento de las horas de trabajo profundo
• Procesos y flujos de trabajo: Menor tiempo de ejecución de los tests, reducción de tasas de regresión, flujos de despliegue más ágiles, reducción del tiempo de lanzamiento al mercado
• Experiencia del cliente: Mejor rendimiento de páginas, menos quejas sobre UX, mejorados tiempos de respuesta
• Rendimiento del sistema: Cálculos más rápidos, menores costes de infraestructura, menos incidentes o retrocesos

3. Conoce a tus clientes

“Mantenerse en el buen camino depende de ser honesto sobre dónde se crea el valor para el cliente,” afirma Malhotra. “Las tendencias pueden sonar emocionantes, pero se convierten rápidamente en distracciones si no ayudan directamente a los clientes a hacer mejor o más rápido su trabajo.”

Ese principio se refleja en cómo muchos equipos ahora vinculan producto e ingeniería con atención al cliente para hacer shadowing en vivo. Algunos ingenieros se unen a llamadas de soporte, sesiones de incorporación o reuniones con clientes para recibir feedback real y sin filtros. Escuchar en directo qué confunde a los usuarios, qué falla y qué se elogia genera empatía e incluso puede afinar la priorización en los equipos de ingeniería. 

Pero escuchar no es suficiente. Para identificar dónde realmente tienen dificultades los clientes, complementa el feedback cualitativo con telemetría de producto. Probablemente tu herramienta analítica (PostHog, Amplitude, Heap) está infrautilizada para este propósito. Empieza a rastrear cómo realmente interactúan los usuarios con el producto: hasta el nivel de clics, interruptores, bucles de navegación y rutas de error. 

Combina estos datos de comportamiento con tickets de soporte para detectar patrones. ¿Una función es ignorada porque es difícil de encontrar? ¿Los usuarios no logran completar flujos de trabajo críticos? Utiliza estos casos como disparadores de alto valor para proyectos piloto centrados en el cliente.

Con el tiempo, construirás de manera orgánica un formulario de "voz del cliente" con puntos de dolor, comentarios, aspectos destacados y bloqueos recurrentes que fluyen de los equipos de éxito hacia las decisiones de producto e ingeniería. 

Es el mismo sistema que el equipo de Senechko utilizó para priorizar el trabajo basado en valor medible para el cliente: “Un gran volumen de clientes y requisitos de baja latencia nos han impulsado a inventar soluciones que las técnicas estándar no podían lograr. Invertir en nuestra plataforma técnica es parte del ADN de la empresa, ya que hemos visto el beneficio tanto para los clientes como para el negocio al hacerlo.”

En última instancia, el verdadero progreso para la ingeniería llegará al diseñar nuevas capacidades que extiendan lo que ya funciona, no al construir alrededor ni al añadir algo totalmente nuevo. Así es como los equipos evolucionan sin romper sistemas comprobados.

“Innovación no tiene que significar disrupción. Debería reforzar lo que ya funciona y ayudar a los clientes a avanzar más rápido con menos esfuerzo,” resume Malhotra.

¿Quieres más ideas como esta? Suscríbete al newsletter de The CTO Club.