- Tags:: #✍️OwnPosts, [[Data team vision and mission]], [[Data culture]]
- Date:: [[2022-10-18]]
![[Pasted image 20221118080031.png]]
Que es bromi. Montar un equipo de Data es súper interesante, pero tiene unos cuantos baches. Sorpresa, ninguno tecnológico. Como siempre: [[🦜 No matter how it looks at first, it's always a people problem]]. Algunos creo que ya _me los he pasao_, otros tengo claro lo que se puede hacer mejor, y luego hay otros que los veo tan complicados, atentan tanto contra la psicología humana, que me dan ganas de cambiar de profesión hasta dentro de unos añitos. No recuerdo tanta pelea como Software Engineer.
## La típica mala herencia y el círculo vicioso
Un cliché del comienzo del trabajo con datos en una compañía es que hayan arrancado solo con data scientists para hacer Data Science. Y como normalmente la apuesta será tímida, serán juniors y sin supervisión dedicada.
Con ese plantel, lo normal será que no haya sensación de entrega de valor ni promesa. Prueba a iniciar cualquier función en una compañía con juniors sin supervisión, a ver qué sale. Y ahora añádele que data en general, [[🗞 Hidden Technical Debt in Machine Learning Systems|es más complicao]].
Probablemente tampoco haya avance interno en cuanto a building blocks necesarios para hacer data (tanto en infraestructura como en procesos). Pero claro, la organización lo que sí que ve es que llevan dos años invirtiendo, with nothing to show for it. Ya sabéis, la vida es una sucesión de clichés hasta que te mueres. De [[📖 Data Means Business]]:
![[📖 Data Means Business#^b8a1d5]]
Esto te complica arrancar. Te toca transmitir la idea de que la organización **no** lleva X años trabajando en esto, que no hay nada reutilizable de ahí. Y encima no empiezas de 0, empiezas de -1:
![[📖 Data Means Business#^3c03c5]]
Aquí es importante distinguir si lo que hay es escepticismo, o desconfianza. El escepticismo es lógico, normal y sano. La desconfianza, no. Esa desconfianza hace cascada en toda la organización (e.g., ¿quién quiere dedicar tiempo a algo en lo que su jefe cree que no va a tener éxito?), lo que impacta a otras obstáculos que vamos a ver aquí, y es muy fácil que simplemente se cree una profecía auto-cumplida.
### ¿Qué he hecho?
Todo el management clásico: hacia arriba y hacia abajo, [pero no hacia los lados ni atrás en el tiempo](https://www.youtube.com/watch?v=4TwkXpYDb7U). Es decir, por un lado, hay que sentar buenas bases en cuanto a Data Science. ¿Qué suele estar más flojo?
- La [[Data methodology|metodología de trabajo]]. Ahí es interesante hacer especial énfasis en escribir para planificar y tomar mejores decisiones ([[Software documentation]]), y también para comunicar, de manera que no haya trabajo sin nada que entregar de ello, por lo menos un análisis ([[🗞️ Agile Data Science]]), aunque sea con resultados negativos.
- Mejorar la ingeniería del equipo, especialmente en cuanto a gestión de la complejidad y sobreingeniería. Esto se hace con supervisión y paireo con Data Engineers / Software Engineers más senior, workshops de clean code... Pero vamos, me sorprendería encontrar un equipo que no pueda arrancar por problemas de ejecución. Es un problema que atacar pensando sobre todo en el largo plazo.
Y luego el macoco bueno, lo verdaderamente complicado. El managing-up de contar que:
- Hay muchos más jobs to be done con datos que no se estarán haciendo (modelado, calidad del dato, analítica profunda...) y su importancia.
- Un equipo de Data no funciona como un equipo de ingeniería de software.
- Que esto va a ser más grande que lo de Lourdes: que te van a haer falta manos (de Fátima) y cabezas.
Para esto, ya sabes, documentos de estrategia (e.g. [[Documento de estrategia inicial en Data Science]]) y comunicación con el C-Level.
### ¿Qué podría haber hecho mejor?
A pesar de que [[📖 Building Analytics Teams]] nos diga que:
![[📖 Building Analytics Teams#^0d7410]]
es muy importante la [[Rule of seven]] y ser más pesado que una vaca en brazos, porque **es clave que el apoyo venga desde arriba del todo.**
## ??? - driven
Si tienes suerte de que se hayan sentado unas bases de Product Management sin [chachas de los datos](https://medium.com/@joseperezaguera/algunas-claves-y-herramientas-para-crear-una-cultura-organizativa-basada-en-datos-e9785a1498ac), los PMs se comerán la analítica básica y llegarás ya con "la idea" de la cultura del dato.
La parte buena es que no tendrás que vender la idea del valor de ser data-loquesea y tu equipo quedará libre de morir por dashboards, que es una tensión muy típica de un equipo de data ([[🗞️ Service pressure]]).
Para arrancar, esto está divino. La parte mala es que no será suficiente. [[🦜 What got you here won't get you there]]. Quizá al principio te puedes permitir ignorar ciertas cosas, pero para ser verdaderamente data-driven (o data-informed, o data-inspired, es que da igual) necesitas un trabajo sistemático.
Por un lado, **no deberíamos confiar en los insights que se puedan sacar si se consultan los datos a la buena de Dios**, tal cuál están en las apps (aunque esos datos estén centralizados en un data warehouse), necesitando hacer 17 joins (y sin tests). Si además se crean métricas y transformaciones de datos "de manera orgánica", sin control, pues estaremos en una situación de desinformación y habremos dejado de vivir en la democracia del dato, para hacerlo en la anarquía, como en política. **Si dices ser data-driven pero no tienes chequeos sobre tus datos... ¿qué te está haciendo de driver y para qué?** De [[📖 Bullshit. Contra la charlatanería]]:
![[📖 Bullshit. Contra la charlatanería#^2d6c96]]
Como he introducido antes, hay jobs to be done que hacer para reconducir: mínimo modelar los datos para que sean más fáciles de consultar y añadirles testing. Un PM, o cualquier otro data citizen, puede hacer dashboards, pero no podemos esperar de ellos que haya nada de data management, quality... [[🗞️ Good Data Citizenship Doesn’t Work]]. Además, las herramientas no están ahí para que lo hagan fácilmente: [The Death of Data Modeling - Pt. 1 - by Chad Sanderson (substack.com)](https://dataproducts.substack.com/p/the-death-of-data-modeling-pt-1?utm_source=substack&utm_medium=email&utm_content=share)
Por otro lado los análisis que merecerá la pena hacer irán creciendo en profundidad, tal que escapará del scope del rol de PM. No por una cuestión de skills, que quizá también, sino sobre todo por tiempo de profundización. De la misma manera que tampoco esperamos que pongan en producción software ellos en plan ad-hoc ([FAQ: What Skills Should a Data-Driven Product Manager Have? - Product School > How Should Product Managers Work With Data Scientists?](https://productschool.com/blog/data-analytics/faq-skills-data-driven-product-manager/))
Ambos puntos les crearán una sensación de "pérdida" de funciones, como mínimo de cierta renuncia a la autosuficiencia con los datos que llevaban hasta ahora. Con lo cual, tendrás que defender qué se gana a cambio. El segundo punto es relativamente sencillo: la complejidad de las cosas a analizar irá subiendo por necesidad y ¿a quién no le va a gustar poder soltar curro? Con lo que las acciones se reducen a anunciar a bombo y platillo que un equipo de Data está también para hacer análisis, y encadenar un par de casos de éxito para que la bola empezara a rodar.
Pero el primero, convencer de que necesitas un trabajo sistemático en calidad del dato, eso es un marronazo de aupa. **Tiene todas las componentes necesarias para ser un trabajo de mierda: impacto indirecto, complejo, y encima a largo plazo.** ¡Y luchando contra el [[Confirmation bias|sesgo de confirmación]] de la peña!
## "No tenemos problemas con los datos"
La primera iniciativa lógica es contar esto, contar de lo que va Data Engineering (y por ende, toda la gestión de los datos). Ejemplos:
- [La salida del armario de Data Engineering](https://slides.com/mariolopezmartinez/data-eng-coming-out).
- [[Fight the Entropy|Fight the Entropy]].
Primero al C-level, y con su beneplácito, luego al pueblo llano.
Lo primero, poner el acento que los datos son productos de estos equipos también, y si somos data-driven, no son productos de segunda: se toman decisiones importantes en base a ellos y se miden respecto de ellos. Especialmente si son equipos de [[📖 Extreme Programming Explained]]: sus feedback loops vienen de esos datos.
Lo segundo era dejar claro el ownership de los datos. Solo puede ser de los equipos. No es posible que resida sobre un equipo central (esto es nosotros). Es decir, que nuestro punto de partida es empezar como un equipo de producto, con vistas a acabar siendo de servicio [[🗞️ Data as a Product vs. Data as a Service]]
Y por último, contar por qué hacer modelado de datos (para facilitar la consulta) y cómo. Y que igual que ponemos servicios en producción a través de flujos definidos, lo mismo haríamos con los datos. Distinguiremos entre datos "con sello de calidad" y una zona sandbox. ¿Cuál es el verdadero objetivo? Intentar ir poniendo freno a la entropía creciente (aunque no arreglemos completamente el problema). La propuesta es que PMs se emparejen con ingenieros para subir esos datos a producción. ¿Vamos a conseguir un modelado perfecto con esto? Seguro que no, eso solo lo conseguiríamos con Data Engineers ([[Analytics Engineering]] really) embebidos en los equipos (y es difícil conseguir el buy-in para empezar directamente con un equipo lo suficientemente grande como para tener embebidos en los equipos más relevantes y además, poder avanzar en trabajo de plataforma).
Mientras tanto, el equipo de Data debería hacer el trabajo sucio de modelar correctamente empezando por aquellos datasets que fueran más críticos.
Al empezar este trabajo, paciencia. Bienvenido a 1995. Vas a oir frases aquí referidas a data que hacía bastante tiempo que se oían en software engineering. Such as: *pero es que no le vemos el beneficio a meter tests y nos va a hacer ir mas lentos.*
Dice [[Nassim Nicholas Taleb]] en [[📖 The Black Swan]] que somos el papel del culo aprendiendo. Para datos, nos toca reaprender en las compañías todo lo que ya se ha aprendido en software:
![[📖 The Black Swan#^d391f9]]
Me sorprende que mucha gente tenga el convencimiento de que sus KPIs, sus análisis... están bien, aún cuando no existen checks por enmedio de pipeline jungles construidos sin planificación. Que si los datos están mal, "se vería" de alguna manera: pero sin fuentes de verdad con las que contrastar. De nuevo, como diría [[Nassim Nicholas Taleb]] también en [[📖 The Black Swan]], **confunden ausencia de evidencia (de errores en los datos) con evidencia de ausencia.**
Amén de la inquietud que te debiera generar el no poder afirmar que tus cisnes son blancos, [[Philip E. Tetlock|Tetlock]] te diría en [[📖 Superpronosticadores. El arte y la ciencia de la predicción#Tasa base o mirada desde afuera]] que vieras qué ocurre en el caso general como ancla. Y el caso general es, un cuadro de comedor:
> Recent Gartner research has found that organizations believe poor data quality to be responsible for an average of $15 million per year in losses. ([Business case for Data Quality](https://www.gartner.com/smarterwithgartner/how-to-create-a-business-case-for-data-quality-improvement))
Una variante de esto es pensar que los datos están siendo "directionally accurate": que sí, que los datos no están perfectos, pero que al menos van en la dirección correcta. El concepto no está mal en sí. De hecho, es muy difícil aspirar a tener todos los datos 100% perfectos, y lo que importa es si están lo suficientemente bien como para tomar decisiones sobre ellos. Como dice la Chief Data Strategy Officer de ThoughtSpot’s:
>You build trust when people understand where the data comes from, and when they understand that even high-quality data will never be perfectly clean. I like how one of our data analytics leaders talks about “Is the data directionally accurate — accurate enough to make decisions on it?”
>
>Now there are some things that have to be perfect. You have to get your blood type right, for instance. But if I’m looking at campaign analytics and customer experience trends, we can make decisions with accurate-enough data. ([Building a Better Data Culture: An Interview with ThoughtSpot’s Chief Data Strategy Officer, Cindi Howson | by Barr Moses | Towards Data Science](https://towardsdatascience.com/building-a-better-data-culture-an-interview-with-thoughtspots-chief-data-strategy-officer-cindi-214d88c873d8))
El problema es que... de nuevo necesitas tener una idea de cómo de correctos están tus datos:
![[Pasted image 20220706103101.png]]
#### ¿Qué he hecho?
- Dar turras como las de [[Fight the Entropy]]
- ¡Esperar ojo avizor! Tranquilo, con el propio crecimiento de la organización, la gente empezará a sacar métricas que no casan entre sí.
#### ¿Qué podría haber hecho mejor?
Éste es de los obstáculos que no estoy muy seguro como afrontar (más allá de ser más pesao que una vaca en brazos).
No es nada fácil tener el [[data literacy]] suficiente para que no te engañe(n|s) con datos ([[📖 How to lead in Data Science#Rigor]]). Se necesita mucho [[actively open-minded thinking]]. Los datos son como ese amigo influenciable. Si le aprietas, te va a decir lo que quieres oir. Usarlos bien es Sistema 2 (reflexión) pero nosotros somos Sistema 1 (impulso) [[📖 Thinking, fast and slow]].
**Y ésta es la máxima bajona de trabajar en Data. Es ir contra la naturaleza humana. Ser el aguafiestas. Es ser el amigo que no te deja tomarte otra y te mete en un taxi para casa.** El que le cuentas un problema y te dice que "depende". Requiere bastante mente fría ser fan de Data. El [[📖 Building Analytics Teams]] nos lo deja claritino:
![[📖 Building Analytics Teams#^6c4cf4]]
Si no se exhibe desde arriba del todo una actitud crítica ante los datos, pues no hay mucho que hacer. Requiere una disciplina bastante recia, pero igual que se ha interiorizado, por ejemplo, el cuestionar todo el rato si una implementación es el paso más pequeño iterativo que se puede dar. Tiene que estar en el ADN. De [[🗞️ Building a data team at a a mid-stage startup. A short story]]:
![[🗞️ Building a data team at a a mid-stage startup. A short story#^844e37]]
Si no, lo que tienes... es esto:
![[🗞️ Building a data team at a a mid-stage startup. A short story#^ba8cf5]]
En futuros posts... (esto luego no lo cumplo nunca):
- Data modeling: No sabes lo que esta roto hasta que te lo enseñan.
- Bueno, ¿y quién se encarga de esto? Politics.
- Nadie quiere modelar.
- Trabajar en Data Science es "living in the antechamber of hope". Thinking in bets.
- Data no es software engineering. ¿Quién detecta oportunidades en Data?