Sobre si mola levantar un equipo de data

• 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 Its 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.

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:

… 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)

🔗 to original context

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:

This makes the starting point particularly challenging and, unlike a start-up, you have this legacy to deal with and history to untangle (p. 64)

🔗 to original context

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 Data Methodology. 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:

En 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)

🔗 to original context

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 Confirmation Bias 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.
• 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:

Another 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)

🔗 to original context

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 te diría en Superpronosticadores 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 ([[how-to-lead-in-data-science#Rigor| 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:

Generally, 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)

🔗 to original context

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:

When 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.

🔗 to original context

Si no, lo que tienes… es esto:

A 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…

🔗 to original context

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?