- Tags:: ✍️OwnPosts, Data team vision and mission, Data culture, Qué hago trabajando con datos en vez de estar zurriendo mierdas con un látigo
- Date:: 2022-10-18
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, 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:
🔗 to original context… even if you haven’t consciously or strategically tried to sort it out before, it’s still likely that huge investment has already been made in it (p. 63)
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:
đź”— to original contextThis makes the starting point particularly challenging and, unlike a start-up, you have this legacy to deal with and history to untangle (p. 64)
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. Es decir, por un lado, hay que sentar buenas bases en cuanto a Data Science. ¿Qué suele estar más flojo?
- La 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:
While I do not advocate spending too much of your time selling up, you will be required to engage in selective and strategic selling and sales activities to convince the upper echelons (p. 164)
đź”— to original context
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, 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).
(El origen de esta ilustración está en Breaking Your Data Team Out of the Service Trap).
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:
đź”— to original contextEn el bullshit, el lenguaje, las cifras estadĂsticas, los gráficos de datos y otras formas de representaciĂłn se utilizan para persuadir o impresionar a la audiencia, distrayĂ©ndola, abrumándola o intimidándola con un flagrante desprecio por la verdad, la coherencia lĂłgica o la informaciĂłn que realmente hay detrás (p. 67)
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 Doesnt 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)
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?)
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 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:
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:
🔗 to original contextAnother related human impediment comes from excessive focus on what we do know: we tend to learn the precise, not the general. What did people learn from the 9/11 episode? Did they learn that some events, owing to their dynamics, stand largely outside the realm of the predictable? No. Did they learn the built-in defect of conventional wisdom! No. What did they figure out? They learned precise rules for avoiding Islamic prototerrorists and tall buildings (…). We do not spontaneously learn that we don’t learn that we don’t learn. The problem lies in the structure of our minds: we don’t learn rules, just facts, and only facts. Metarules (such as the rule that we have a tendency to not learn rules) we don’t seem to be good at getting. (p. xxvi)
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, Tetlock te dirĂa en 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)
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)
El problema es que… de nuevo necesitas tener una idea de cómo de correctos están tus datos:
¿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 (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:
🔗 to original contextGenerally, people do not enthusiastically embrace what they do not understand. You won’t find many, if any, of that generation of executives and managers who will freely admit that they do not fully understand basic computing technology (…) I am certain that there is an infinitesimally small percentage of that managerial population who understand basic descriptive statistics, let alone advanced analytics and AI (…) Given that this is a reality for the next 7 to 10 years, what do we do about it? Patience and clear communication are recommended for a start. Normally, I would have said concise communication, but in this case, a serious and significant amount of talking, writing, coercing, and convincing will be needed on your part. (p. 208)
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:
🔗 to original contextWhen the turn comes to the growth initiatives, the lead PM presents a new splashy landing page redesign that they launched. (…) Everyone looks at the CEO to see what she thinks. She’s quiet for a while but then opens her mouth. “What are the metrics so far? Do we know if the customer acquisition cost went down?” she says, and you smile to yourself, because you’ve been hoping for this question. (…) The excellent news is the CEO is pushing for teams to use data as the truth. Once there is an organizational pressure to be more data driven, this is a time to accelerate the way the data team works with other teams.
Si no, lo que tienes… es esto:
🔗 to original contextA culture that fundamentally is at odds with being data driven. A culture of celebrating shipping, versus celebrating measurable progress and learnings. To the extent teams actually use metrics, they are inconsistent, poorly measured, and in some cases at conflict with other teams…
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?