Por qué los equipos de datos técnicamente excelentes siguen fracasando

• El valor de un equipo de datos no proviene de la producción de pipelines, esquemas y dashboards, sino de cambiar la toma de decisiones de la organización; entre los datos y la acción se necesita una capa de interpretación: la perspectiva (Perspective)
• Data-Perspective-Action es un modelo operativo que construye datos confiables, los interpreta según el contexto del negocio y luego propone acciones concretas de forma continua
• En la 2026 AI & Data Leadership Executive Benchmark Survey, el 93% de los líderes de datos e IA señaló la cultura y la gestión del cambio como la principal barrera para la adopción, mientras que solo el 7% apuntó a la tecnología
• Con documentos semanales de una página, un sistema de métricas clave, codiseño con stakeholders y la regla de adjuntar recomendaciones de acción a todo análisis, es posible convertir la perspectiva en un hábito y conectarla con decisiones reales
• Cuanto más la IA genere pipelines, análisis iniciales y dashboards, más el conocimiento del dominio y la confianza se volverán el diferenciador, por lo que los equipos de datos deben ir más allá de entregar resultados correctos y construir una realidad compartida

---

Por qué se necesita Data-Perspective-Action

• El valor en una organización no se crea con entregables de datos, sino con decisiones; entre la salida en bruto y la acción real hace falta una capa de interpretación: la perspectiva
• Incluso equipos técnicamente competentes y con datos precisos pueden volverse irrelevantes para la toma de decisiones si solo optimizan volumen de trabajo, como atender solicitudes, cerrar tickets o publicar dashboards
• Incluso un sistema de datos bien diseñado puede perder prioridad, quedarse sin presupuesto o desaparecer en una reestructuración si no convierte en hábito la conexión con el trabajo y las decisiones
• Data-Perspective-Action es un framework que repite de forma intencional el proceso que va desde los datos, pasa por una interpretación con opinión y termina en decisiones concretas

Punto de partida del framework

• En una agencia de publicidad, un reporte mensual tardaba 4 semanas en elaborarse y para cuando se entregaba ya estaba desactualizado, pero al automatizar el workflow en alrededor de un día, el tiempo restante se aprovechó para modelos predictivos
• No era un modelo complejo, pero mostraba los resultados esperados al mover presupuesto entre canales, lo que permitió que el cliente viera el retorno esperado por adelantado y ejecutara cambios de canal y experimentos
• A partir de esa experiencia se formó la secuencia datos, interpretación y decisión específica, y luego el mismo modelo se aplicó en varias organizaciones

Paso 1: Data confiable

• La capa de Data incluye infraestructura, confiabilidad, consistencia, flujo de información, pipelines, esquemas, modelos y dashboards, y aquí se concentra la mayor parte del trabajo diario de los data engineers y analytics engineers
• Sin datos confiables no se puede construir perspectiva, pero si el trabajo se detiene en recibir solicitudes → procesarlas → cerrar tickets, la carga de interpretar datos correctos pasa a stakeholders que no están preparados
• Un equipo construyó 200 dashboards con pipelines sofisticados, esquemas y lógica de actualización validada, pero solo 10 se abrían antes de una decisión real
  • Los otros 190 se crearon sin que el equipo de datos y los stakeholders acordaran para qué decisión servían
  • Se eliminaron dashboards innecesarios, pero la causa raíz era la falta de una definición compartida del propósito del trabajo
• Si uno se queda en la capa de Data, el backlog y la carga de trabajo pueden mantenerse, pero la distancia con las decisiones reales crece y el equipo fácilmente pierde prioridad

Paso 2: Perspective

• Perspective es la capa que convierte a un equipo que informa en uno que impacta a la organización, y la expertise del dominio para juzgar si una métrica sirve para una decisión específica es el punto central
• En la 2026 AI & Data Leadership Executive Benchmark Survey, el 93% de los altos líderes de datos e IA eligió la cultura y la gestión del cambio como el principal reto de adopción, mientras que el 7% eligió la tecnología
  • Brecha entre cultura/gestión del cambio y tecnología: {b:93,7}
  • Fue la mayor brecha en 15 encuestas anuales, y a lo largo de todo el período la cultura y la gestión del cambio aparecieron repetidamente como barreras más importantes que la tecnología
  • Aunque las organizaciones inviertan en infraestructura y talento, los resultados son limitados si falta capacidad para interpretar y ejecutar el cambio
• Ahora que la IA puede crear pipelines, análisis iniciales y dashboards a partir de prompts, el cuello de botella se mueve de la construcción a la confianza
  • Cuanto más aumenta el volumen de salidas, más importantes se vuelven los guardrails como calidad de datos, gobernanza y una definición clara de la verdad
  • Mick Dreeling, de Netflix, cree que en un entorno donde los stakeholders consultan directamente a agentes, probablemente recaerá en los equipos de data engineering la responsabilidad de garantizar respuestas correctas y elevar continuamente el estándar
  • Shridhar Iyer, de Meta, considera que aunque los agentes absorban conocimiento general, la expertise de dominio sigue siendo propiedad intelectual que no desaparece
• Los profesionales que desarrollan Perspective de forma sistemática aumentarán su valor a medida que evolucionen las herramientas de IA, mientras que el trabajo que se queda solo en la capa de Data será más fácil de automatizar

• La trampa de la objetividad

  • Los especialistas en datos pueden sentir que ofrecer una interpretación invade atribuciones ajenas y caer en la pasividad de presentar análisis sin contexto
  • Los stakeholders, con tiempo limitado y múltiples prioridades, terminan interpretando por su cuenta dashboards que entienden a medias o recurriendo a la intuición
  • Los datos no hablan por sí solos, así que si el equipo de datos no los interpreta con cuidado a partir del contexto y la experiencia, alguien más lo hará

• El problema de no ver más allá de la entrega

  • Aunque los pipelines corran, los dashboards se abran y las pruebas pasen, los stakeholders pueden descargar un CSV, abrirlo en Excel, agregar columnas y fórmulas y rehacer el análisis cada vez que lo necesiten
  • Ese tipo de sistema puede estar bien técnicamente, pero en la práctica está siendo rodeado
  • Si les preguntas a 5 stakeholders qué decisiones están tomando ahora y en qué tienen incertidumbre, puedes encontrar problemas que se resuelven en uno o dos días
  • La confianza que se acumula al resolver de forma proactiva problemas pequeños crea la base para que el equipo de datos participe en reuniones antes de la decisión, no después

• Entrenar la perspectiva con una página semanal

  • Cada semana se redacta una sola página con estas tres partes
    • Un párrafo que resuma los hechos que muestran los datos
    • Un párrafo que interprete, con opinión, lo que eso significa para el negocio hoy
    • 1 o 2 bullets concretos con lo que debería hacerse después
  • Si compartes esto con un gerente, colega o responsable del negocio y repites el ciclo de recibir una retroalimentación durante 3 meses, cambia tu intuición sobre los datos que realmente importan para quien decide
  • El trabajo más importante empieza con la propuesta de acción, y aunque incomode, hace falta entrenarse para formar una opinión propia

• Métricas macro y micro

  • Las métricas macro son el pequeño conjunto de cifras clave que responde si la empresa está sana, y las métricas micro son las cifras de entrada que explican el movimiento de las macro
  • Monisha Kanoth, de Apple, considera que una north star metric sólida y acordada por todo el negocio es la base de la confianza
  • Para un líder de marketing que recibía datos de decenas de fuentes, se reconstruyó el sistema de reportes en torno a 3 métricas macro y 5 señales micro
  • En un trimestre, dejó de estar en una situación donde no sabía qué números confiar, y pudo hablar con precisión en conversaciones con el directorio sobre qué impulsaba el crecimiento y qué no
  • Al definir las métricas importantes y priorizar su integridad, también mejoraron las preguntas y la calidad de las respuestas del equipo de datos

• Codiseñar con stakeholders

  • Lanzar la versión 0.8 consiste en mostrar el resultado antes de terminarlo e involucrar a los stakeholders en el último 20% del proceso de construcción
  • La cocreación genera sentido de propiedad sobre el resultado, y ese sentido de propiedad convierte el entregable en un compromiso de acción real
  • Un stakeholder escribió 100 preguntas realmente importantes, y la mayoría de las preguntas que surgieron durante los años siguientes ya estaba en esa lista
  • La lista se usó tanto como roadmap de construcción como herramienta para controlar el alcance
  • Cuando llegaba una nueva solicitud, ya no se evaluaba solo si había que rechazarla, sino si era más importante que algo previamente acordado

• Convertir la narrativa, no el link, en el entregable

  • Si solo compartes una consulta SQL, una hoja de cálculo o un link a un dashboard, le estás pasando al usuario el trabajo más difícil: interpretar
  • Redactar una narrativa, aunque sea breve, te obliga a elegir qué es importante y a asumir responsabilidad por una interpretación concreta, y crea un entregable sobre el que se puede dar feedback, rebatir y corregir
  • La IA generativa puede usarse para pulir frases, pero no debe encargarse del pensamiento en sí
  • Escribir es un proceso de pensamiento, y la IA no puede desarrollar en tu lugar una perspectiva única
  • Si no participas directamente en el pensamiento y solo entregas tal cual una narrativa generada por IA, terminas saltándote la capa de Perspective que se acumula con el tiempo

Paso 3: Action

• La distancia entre una recomendación y una decisión real dentro de la organización es grande, y los equipos de datos tienden a subestimar tanto el trabajo necesario para esa transición como su propia responsabilidad en ella
• El vacío entre el análisis y la reunión donde se decide debe llenarse con recomendaciones claras, estimación del tamaño de la oportunidad y apoyo continuo
• Si el equipo de datos no participa en esta zona, la interpretación, los intereses y el calendario de los stakeholders llenarán el vacío, y se cederá el control de la parte más importante del trabajo

• La regla de no presentar solo datos

  • Todo análisis debe incluir una acción recomendada; los datos no deben presentarse solos
  • La restricción de tener que recomendar algo al final cambia el alcance del trabajo desde el inicio
    • La investigación se enfoca en una pregunta específica
    • Se instrumentan métricas relacionadas con la decisión
    • Se considera qué información necesita un líder para moverse
  • En un caso donde un modelo que cuantificó una oportunidad de crecimiento no se tradujo en acción por parte del liderazgo, el problema no fue la precisión del análisis sino la falta de recomendación y de contexto compartido
  • Si se salta de Data directamente a Action, se pierden la construcción de relaciones, la cocreación y la generación de confianza, por lo que la recomendación puede quedar sin ejecutarse

• Tamaño de la oportunidad y apoyo continuo

  • Cuando de un análisis surge una hipótesis, el propio equipo de datos debe cuantificar cuánto vale la oportunidad y por qué debería priorizarse
  • Aunque la estimación pueda estar equivocada, una cifra concreta le da a quien decide algo que puede cuestionar, y una estimación debatible tiene más probabilidades de convertirse en decisión que una dirección ambigua
  • Haberla presentado una vez no significa que se reflejará en el roadmap, y llegar a la capa de Action puede tomar meses
  • Hace falta mantener una learning agenda para dar seguimiento a las recomendaciones ejecutadas y a las que no, y seguir apoyando las que aún son importantes con cifras actualizadas
  • Si se detiene el trabajo de seguimiento solo porque la primera presentación no fue aceptada, se abandona una parte clave del trabajo: conectar con la decisión

Estructura organizacional que sostiene el framework

• La unidad base ideal es un dúo asignado a un área específica del negocio: 1 analytics engineer y 1 analista
  • El analytics engineer se responsabiliza por la solidez del sistema
  • El analista se encarga de la narrativa, la relación con stakeholders y las recomendaciones de acción
• Un engineer sin un partner que se encargue de la narrativa tiende a construir por completitud antes que por decisión, y un analista sin un partner que garantice sistemas confiables tiene más dificultades para producir evidencia convincente
• No hace falta reorganizar de inmediato una organización existente; se puede validar el modelo asignando ambos roles a un área del negocio durante un trimestre y luego escalarlo
• Si, como en una empresa en etapa temprana, el trabajo de infraestructura consume la mayor parte de la capacidad del equipo, en vez de un dúo se puede proteger tiempo para compartir perspectiva
  • Realizar una revisión semanal del negocio
  • Abrir demos mensuales para equipos que no se atienden directamente
• Más importante que el organigrama es el hábito de repetir Perspective

Ritmo operativo que se acumula a largo plazo

• Si el trabajo de construir perspectiva y respaldar acciones se repite cada semana, su efecto se acumula a lo largo de meses y años
• Cuanto más se participa en el proceso de decisión, mejor se distinguen los pipelines sin razón de ser, las alertas que son casi puro ruido y las inversiones en infraestructura que realmente harán falta después
• El rol del equipo de datos es construir una realidad compartida en la que los miembros de la organización puedan confiar en común sobre la situación actual y su significado
• Data-Perspective-Action es un modelo operativo que mantiene visible que el propósito del trabajo técnico es tomar mejores decisiones, y que los pipelines y los esquemas existen para servir a esas decisiones