Conversación con Israel Olalla

Israel Olalla es un Customer Engineer Manager del equipo de Google Cloud.

Sus experiencias se han desarrollado en el campo de los motores de búsqueda, los asistentes virtuales, los sistemas de recomendación y los juegos, trabajando en compañías como Oracle, Wolters Kluwer o Google.

Sus intereses incluyen Tensorflow, Bigquery, buscadores, el lenguaje GO y las redes neuronales.

Le puedes encontrar jugando con sus 3 hijos, perdido por Menorca o soñando despierto

Siempre  me gusta comenzar estas conversaciones con un pequeño viaje al pasado. En tu caso, estudiaste Business Administration pero has acabado desarrollando tu carrera profesional en el ámbito de Data & Analytics. Me gustaría que me contaras tu evolución y en qué momento tuviste claro que el mundo del Dato era tu vocación

Supongo que es un viaje bastante común, llegué a la informática haciéndome preguntas y  para contestarlas he utilizado datos, la curiosidad es lo que me ha ayudado a encontrar nuevas preguntas y normalmente usando ordenadores y experimentos he conseguido contestarlas.

Imagino que durante todos estos años habrás sido testigo de los grandes cambios acaecidos en el campo de Data & Analytics. ¿Cuáles han sido, desde tu punto de vista, los cambios más relevantes? (nota: aquí la idea es que puede reflexionar sobre cambios relacionados con plataformas, procesos, modelos, etc) 

En mi opinión los cambios principales vienen del abaratamiento del Hardware y el Software, gracias al movimiento Open Source tenemos soluciones como Hadoop o Spark que permiten gestionar grandes volúmenes de datos sin arruinarse y por otro lado es el abaratamiento del Hardware, no sólo por la Ley de Moore, sino también por la llegada de los modelos de Pay As You Go, de la nube, estos dos cambios han permitido que se puedan lanzar muchos experimentos más baratos, que puedas definir un cluster de cálculo en minutos y que las pruebas no te arruinen un presupuesto.

Por otro lado hay MUCHOS más datos, la llegada de los móviles ha provocado la explosión de tipos de datos, fotos, audios, metadatos, feedback explícito, implícito, videos y gracias al abaratamiento de las plataformas, se puede guardar esos datos. Es cierto que hay preocupación por los formatos de los datos y la obsolescencia de los formatos cerrados, Vint Cerf ya avisa de ese peligro, pero en general la cantidad de datos disponible ha tenido un cambio muy positivo.  Los proyectos de open data de las administraciones públicas, aunque limitados, son una prueba más de cómo cada vez existe más interés en facilitar el acceso a los datos. Han madurado mucho proyectos como Kaggle o Numerai, que cuentan ya con decenas de miles de Datasets y con millones de científicas de datos que los usan a diario.

Todos estos datos empiezan a tener otros efectos, como que los usuarios de las aplicaciones son más exigentes, se preocupan de las recomendaciones que reciben, por la preocupación del uso de esos datos  y por el efecto cámara de eco que tienen los sistemas de recomendación automática. 

Por último, para mi la gran revolución de este primer cuarto de siglo ha sido la demostración de que se podían hacer sistemas de clasificación y reconocimiento basados en redes neuronales profundas, el uso de las redes convolucionales en reconocimiento de imágenes y la llegada de las redes adversariales, que han abierto tantos campos de optimización y mejora continua  con proyectos como AlphaGo , AlphaFold o GPT, donde se ha demostrado que se puede utilizar ML en muchos más campos de los que se podían pensar. Pero si somos realistas nos quedan muchos más retos por investigar y descubrir y el avance hoy en día puede parecer lento en algunas áreas, pero es básicamente porque formar talento es un proceso lento y para resolver los problemas de ML e IA hace falta gente con altos grados de formación y especialización.

De todos estos cambios, uno que creo que conoces particularmente bien por tu paso por Oracle y Google es el cambio de paradigma: de plataformas on-premise a soluciones basadas en cloud. ¿Cuál crees que fue el punto de inflexión que provocó el cambio? ¿En qué casos de uso todavía tiene sentido apostar por modelo on-premise? 

La llegada de los móviles provocó la explosión de los datos, el uso desde cualquier sitio de las infraestructura y picos de peticiones, lo que para las empresas se traduce en la necesidad de tener modelos de costes capaces de adaptarse con más agilidad a lo desconocido y a los picos de demanda. Los modelos de pago por uso se adaptan mejor a las nuevas necesidades. Además tienen un objetivo de optimización nuevo y más sencillo: antes el responsable de abaratar el coste era el departamento de compras, con una capacidad limitada de decisión y de compra: en el nuevo paradigma TODO equipo puede tener un incentivo continuo de mejora y ahorro, lo que se ha dado en llamar FinOps, así todo el mundo sabe en qué se gasta el dinero y como lo pueden abaratar.

Creo que cada vez quedan menos cosas que no se puedan llevar a la nube, el viejo mito de la privacidad y el cumplimiento normativo, que eran mejor en sistemas on premise, cayó, por culpa de los ransomwares y gracias a la aparición de nuevos servicios de los proveedores de nube como Soberanía Digital.

Por cierto, te lo quiero poner un poco difícil en esta entrevista, así que te añado una cláusula: a partir de ahora, en el resto de respuestas solo puedes nombrar Google o productos Google en dos ocasiones más como mucho. Dicho esto, y siguiendo con el tema de infraestructura, mi siguiente pregunta es sobre PYMES. ¿Qué infraestructura de datos debería tener una PYME para asegurar que le saca valor al dato a un coste razonable?

Yo creo que lo primero es recoger todos los datos que puedas necesitar, guardarlos en almacenamientos baratos y cuando tengas el equipo para hacer las preguntas y las respuestas plantearse como buscarlo. Hay varias soluciones que permiten explorar los datos en diferentes formatos de origen. 

¿Qué tipos de datos? Los que de alguna forma  estén relacionados con el día a día del negocio, CRM, ERPs, interacciones de los usuarios con nuestra aplicación web o app, esos datos no se tiran por cambiar de un proveedor, no se borran pasado un año, se guardan en un almacenamiento barato y en el futuro puede que nos sirvan para algo. La gente es la que le puede dar valor a los datos: puede que hoy no seas capaz de comprender y explicar eventos pero pasado un tiempo puedes utilizar esos datos para entrenar nuevos modelos de ML.

Hay dos problemas en este efecto hámster de los datos. El primero es el formato: que no se quede potencialmente obsoleto. El segundo es el del coste del almacenamiento. Contra el primero creo que la respuesta son los estándares abiertos y para la segunda, por suerte tenemos la ley de Moore que seguirá abaratando los costes de almacenamiento.

Pasemos ahora a hablar de Machine Learning e Inteligencia Artificial. Me gustaría que me dieras tu definición de los dos conceptos

Machine Learning es el proceso por el que podemos enseñar tareas a un software. Una de las formas de enseñarles hasta hoy ha sido tener ejemplos y entrenar una red neuronal con esos ejemplos y a partir de un cierto nivel de calidad, el sistema de ML puede predecir. Reconocer, etiquetar y marcar objetos en fotos, jugar a juegos de ordenador, como pong o blocks, pero también de estrategia como Starcraft o Go o el Ajedrez,  desentrañar el plegado de proteínas, detectar retinopatías, conducir coches de forma autónoma o predecir el riesgo de impacto de meteoritos, son algunas de las tareas que se pueden hacer hoy en dia con Machine Learning.

Inteligencia Artificial es un concepto más amplio, son el conjunto de software y sistemas que permiten a un sistema informático aprender de forma autónoma y tomar decisiones correctas. El objetivo de AI es tener una inteligencia como la humana, capaz de aprender en cualquier escenario y tomar decisiones correctas, ¿Pero cómo podemos saber si una AI es completa y buena? ¿Puede un sistema de AI usar el conocimiento adquirido en un área en otra totalmente nueva?¿Pero cómo puede una cosa llegar a tener consciencia? Si tengo una sala con todos los libros escritos en chino y todos los diccionarios de chino, ¿eso significa que la sala sabe chino? ¿Cómo puedo estar seguro de que esa AI cumplirá con los estándares éticos y morales de la sociedad occidental? Hay pruebas como el test de Turing que sirve para validar si la conversación de un bot es suficientemente “humana” y existen competiciones de Darpa para el Deep Learning o conducción autónoma, hay competiciones como CASP para validar que el plegado de proteínas es válido. Pero muchas preguntas siguen sin resolverse y son precisamente esas preguntas, esos retos los que hacen interesante seguir trabajando en IA y seguir investigando dónde está el límite, porque en el camino descubriremos cosas fascinantes y en muchos casos útiles para la humanidad, ayudando a los humanos a conseguir hacer más y mejor.

Aparte de la infraestructura ¿Qué herramientas y soluciones son necesarias para poner en marcha con éxito un proyecto de Machine Learning? Y en el caso de proyectos de Deep Learning ¿qué grandes diferencias ves respecto a Machine Learning?

Por decirlo en Orden yo creo que es algo así:

• Definición del experimento: ¿Cuál es la hipótesis que queremos validar?; ¿Qué problema queremos resolver?. Queremos vender más y por eso usamos un sistema de recomendación de productos. Queremos encontrar un patrón en una imagen, ver si una soldadura está bien hecha, queremos reconocer el contador y hacer la lectura con una foto, leer una matrícula en una foto, etc. 

• Una vez tenemos claro qué problema queremos resolver, decidimos si hay una API pública que lo resuelve, por ejemplo, ¿Hay una API que me pueda dar OCR? ¿Existe una buena API de traducción automática? ¿Existe una API que me permita de forma sencilla establecer correlaciones entre los datos que tengo en mis tablas?  ¿Tengo una API que me permita dar recomendaciones de productos? Si la respuesta es que sí, pruébalas, valida el modelo de coste y úsalas. Pero si no te sirven o si quieres tener un control más fino de la evolución del producto, si no son suficientes para cubrir las necesidades, entonces tienes que empezar a hacer tu propio modelo y para eso vas a necesitar datos. ¿Cuántos datos? Depende del tipo de problema que se quiera resolver. Para algunos problemas podremos usar la representatividad estadística como medida previa, pero en la mayoría tendremos que fiarnos de las medidas que tomemos con el dataset de testeo y validación. Para el problema de detectar un contador con unas 300 fotos y el dataset de imagenet (14M) pudimos hacer algo razonable.  Una vez tenemos el dataset decidido, lo prepararemos para el entrenamiento  y lo guardaremos en un catálogo, idealmente en un sistema de control de versiones o en un FS que soporte versionado. 

• Una vez tenemos los datos y el problema empezamos con el proceso iterativo, en el que analizamos datos, probamos modelos y volvemos al punto anterior si es necesario. ¿Cómo analizamos datos y probamos modelo de DNN/ML? pues depende de las preferencias de cada equipo, hay gente que prefiere R Studio, hay gente que prefiere Jupyter notebooks, Databriks, otros prefieren programar en C++, Go, Lua ó Java y eso les lleva a elegir unas herramientas y frameworks en función de sus preferencias, Colab + Python + TensorFlow son sospechosos habituales.

• Una vez empezamos a tener un modelo -que es capaz de clasificar, predecir, recomendar, etc- lo siguiente es validarlo con el dataset de testeo y el de validación. Si las medidas de Fairness, Skew, Matrix Error (TF/IDF), Precisión o Recall son las que nos permiten evaluar si el modelo funciona bien, o al menos mejor y más rápido que un humano, si es así ya tendríamos el experimento listo, y  ya podremos empezar a validar con PMs y usuarios finales el uso del modelo, para este paso creo que es muy interesante la idea del presupuesto del experimento, es decir, empiezas probando con 100 usuarios y si todo va bien, en la siguiente interacción tienes un presupuesto de 1.000, 100.000, etc. y en cada una de esas iteraciones del experimento.

• Fantástico, tu modelo, predice/clasifica/reconoce/recomienda bien y todo el mundo está encantado con tu solución. Pero recuerda que todo cambia, lo mejor es seguir guardando metadatos de las predicciones, saber qué predijiste, cuándo y si puedes, por qué predijiste ¡fantástico! (aunque en muchos casos es imposible saber bien el porqué de la predicción). 

Todo este ciclo que he comentado se parece bastante a un ciclo de MLOps, hay varios frameworks completos para poder gestionarlo. Mis favoritos son Vertex, Tensorflow y Kubeflow, hay varios que no he tenido la suerte de probar como Seldon o MLFlow.

Por último pon el foco en la gente, en el equipo , es lo más importante de todo. Desde el equipo, su conocimiento, lo que quieren aprender y sus habilidades es desde donde se tiene que definir la organización, estructura, compensación y estrategia y un buen equipo es lo más caro de conseguir. Por ejemplo, hoy hay DataScientists y existen equipos de DevOps, pero es muy raro encontrar los perfiles que aúnan las dos especialidades.

Por otro lado también es importante elegir herramientas que minimicen el Lock-In y que abaraten la deuda técnica y yo creo que una de las formas de minimizarlo es evitando formatos cerrados y proyectos cerrados. ¡¡Viva el software Open Source!! 

Por último, fallar barato, es fundamental. Barato desde el punto de vista emocional, que no le dé miedo al equipo fallar a probar cosas nuevas a salirse de los establecido y por otro lado a diseñar los experimentos de forma que se pueda iterar rápido y barato. Si queréis, podéis aprender más del pretotyping de Alberto Saboia, es una gran fuente de inspiración.  

Cuando nos conocimos, allá por el año 2017, tú, desde Google, ya defendías las bondades de Tensor Flow. Desde entonces hasta ahora, ¿cuáles han sido los grandes progresos que ha habido en Tensor Flow? ¿Qué casos de uso te parecen más espectaculares? Seguramente te acabas de dar cuenta que aquí vas a tener que utilizar uno de los dos comodines “Google”

Tensorflow, es un buen ejemplo de proyecto OpenSource, que por la vitalidad de la comunidad es una apuesta de futuro clara. Por suerte existen más: Theano, Keras, Scikit Learn o Spark MLib () , lo que demuestra que desde las diferentes comunidades se apuesta por las DNN para resolver cada vez más problemas.

Para mí, los tres avances más significativos de Tensorflow son entorno a TFLite, que es la versión pensada para resolver el problema de la predicción en XX ms, para llevarlo a las aplicaciones en tiempo de predicción incluso para resolver el entrenamiento en el dispositivo y que abre las puertas para resolver el reto del Federated Training.

El siguiente gran avance para mi ha sido la llegada de los instrumentos que simplifican la gestión del ciclo de ciclo de vida del modelo, los TFX Pipelines son una demostración de la madurez de la plataforma.

Y por último lo que me gusta más es la evolución de las TPUs, o Tensorflow Process Units. Cuando eres serio resolviendo un problema de software tienes que diseñar Hardware para resolverlo y en el caso de las TPUs es por el consumo eléctrico, utilizar GPUs para resolver problemas de vectores o tensores es un claro exceso, por lo que se pueden hacer CPU optimizadas para el cálculo de operaciones de multiplicaciones de matrices MUY grandes y que por lo tanto reducen el tiempo frente a las GPUs y al necesitar menos Hardware reducen radicalmente el consumo eléctrico. Y lo más interesante es la llegada de las TPU Edge o coral que consiguen llevar a dispositivos edge y especialmente móviles la aceleración en la predicción y ayudar a  resolver el entrenamiento en local y abrir la puerta al Federated Training.

Por tu posición, estoy seguro que habrás visto empresas que le sacan bastante valor a los datos y otras que no. ¿Cuáles son las grandes diferencias entre los dos tipos? 

Para mí la más importante es la cultura, nuestro mundo cambia muy rápido, es impredecible. Si tienes una cultura que enseña que te puedes equivocar, que busca lecciones y aprendizajes, no culpables, que valora el fallo como una oportunidad de aprender y mejorar, que busca equipos diversos, que integra, que valora al diferente y reconoce el talento y el esfuerzo es más fácil atraer el talento, es más sencillo que la gente buena y capacitada quiera trabajar en ese equipo y se sienta identificada con el equipo y con los valores.

Y esa cultura, esa visión, te lleva a  tomar decisiones basadas en datos y a respetar los datos, y es curioso porque cuando la organización se da cuenta de que sin datos no se toman decisiones, las reuniones y la forma en las que se preparan cambian y se alinean con el Data First.

Hablemos ahora de las personas. ¿Qué perfiles son necesarios para tener un buen equipo de Data & Analytics?

Talento, es sin lugar a dudas el mayor reto que tenemos por delante, en dos ámbitos. El primero es el campo del research de AI/ML: necesitamos que haya más gente innovando más en los modelos y sustrato teórico, explicabilidad de los modelos, nuevas funciones de activación, transferencia, metamodelos y más avances en tipos de redes, que es muy caro y muy difícil de conseguir. El segundo ámbito es en la democratización de ML e IA, donde tenemos que entender los modelos y algoritmos que usamos a diario y tener pensamiento crítico para abandonarlos, buscar alternativas o entender su impacto real.

Es buscar a perfiles que les guste trabajar con datos, suena una obviedad, pero no lo es, hay gente orientada a problemas, otros a personas, otros a procesos y otros a datos , aunque la mayoría de la gente somos capaces de cambiar de orientación, se pueden encontrar perfiles con sesgos muy claros, normalmente la gente orientada a datos, controlará SQL, conocerá varias bases de datos y entenderá sin problemas las diferencias entre Orientación a Objetos/Tablas y orientación a documentos, SQL vs NOSQL  y te podrá decir sin vacilar 3-4 recetas habituales en el data cleansing, será capaz de pensar en Gb/Tb/Pb y seguramente utilizará alguna herramienta analítica de preferencia, ya sea R o python + Jupyter.

Lo más complicado suelen ser los perfiles que mezclan varias disciplinas con profundidad. Un Software Engineer, que controla de Data , programa ML, controla de contenedores y sabe de DevOPs es un Unicornio. Igual que un perfil que sepa de ML, Data y Hardware, que pueda resolver problemas en los límites de Throughput , latencia , disponibilidad y refresco.

De todos esos roles, tengo la impresión, que los más buscados hoy en día son los perfiles tipo Data Engineer. ¿Qué consejo le darías a una empresa que busque Data Engineers? ¿Reconvertir a sus Software Engineers? ¿Crear cantera?  

Siempre apostaría por crear cantera, los perfiles que saben programar con soltura en uno o varios lenguajes de programación son capaces de adaptarse a más tipos de problemas y suelen resolver y automatizar las soluciones, por lo que Software Engineers con interés por los datos y ML, suelen ser perfiles que se adaptan bien a los cambios y retos de los proyectos.

También hay muy buenos analistas de negocio, gente que viene del negocio, de ventas, de marketing, de operaciones y que con las herramientas correctas se convierten en buenos Data Engineers, porque conocen muy bien el problema de negocio y las necesidades del cliente. Suelen ser casos más excepcionales, pero acaban aprendiendo python, SQL y lo que haga falta para contestar a las preguntas que se plantean sobre sus clientes.

Por último, “solo llegarás rápido, con amigos llegarás lejos”. Creo que es mejor crear equipos y dinámicas ágiles más que llaneros solitarios o equipos aislados; los silos y los llaneros solitarios suelen esconder deudas técnicas que tarde o temprano tendrás que pagar. 

Me gustaría preguntarte ahora por los Datawarehouses ¿Cuáles son las tres reglas de oro para que un DataWarehouse cumpla las necesidades de negocio? 

La primera es que tiene que ser un DWH para toda la organización, que sea fácil de gestionar y crecer y no esté limitado por el Hardware o los sistemas. Hay una tendencia a ver el DWH como una versión barata de la base de  datos OLTP, es como ver un almacenamiento barato y consultable del ERP, el ecommerce o de CRM, pero ¿por qué no puede ser de los tres a la vez? Uno que pueda soportar diferentes paradigmas de datos , Tablas, Documentos, que pueda y que pueda trabajar con diferentes formatos. 

La segunda es que todo el mundo debería poder acceder, lo que te lleva a poder tener un modelo de seguridad serio y que te permita gestionar el acceso , controlarlo , auditar, enmascarar datos de PII,  etc.

La tercera es que sea extensible, que pueda añadirse fácilmente herramientas, ya sea de ETL, de visualización y BI, de analitica, de ML un DWH que te permite coleccionar “síes”.

¿Y cuáles son las tres cosas que nunca hay que hacer cuando estás construyendo un Data Warehouse?

Evitar el Lock-In en todas sus formas, un DWH te tiene que permitir llevarlo a una herramienta Open Source en minutos/horas, de forma que el próximo experimento lo puedas hacer con la herramienta que quieras sin costes  ocultos. Esto está bastante relacionado con los formatos de almacenamiento y con los modelos de licenciamiento.

No guardar el modelo de datos en un repositorio de versiones, el modelo de datos tiene versiones y se documenta en un git o sistema de control de versiones, un doc o un wiki estan bien, un script de creación en .sql o en python está mejor. Los comentarios del código se pueden leer y buscar y puedes asignar casos, versiones incluso branches a cambios en el modelo y ya extra ball nunca se lanza una versión nueva del DWH sin rollback.

¿Cuál es el Dataset más complejo de gestionar que has visto? ¿Cuál era su mayor complejidad?

Yo creo que lo que le da más complejidad a un DataSet y a un modelo de datos son lo años de mantenimiento. En banca hay datasets enormes, pero que normalmente están muy bien hechos y los cambios están bien documentados, en retail/travel hay muchos cambios en los datos, pero poco en los modelos, acostumbran a tener modelos razonables y razonablemente  bien documentados y normalmente cuando se añaden nuevas funcionalidades se añaden en nuevas tablas.

Para mí los peores son los que no están bien documentados, y  tratan datos no estructurados, p.e.: corpus legales, corpus documentales en general , esa es una tormenta perfecta, con modelos de referencias internas diferentes, en unas fases usan FK, en otras un tabla de referencia y en otro momento se deciden por el marcado en el contenido. 

¿Cómo te mantienes al tanto de los grandes avances en tu ámbito de trabajo?

Siguiendo a gente relevante que dice cosas interesantes, como Luis Velasco y su canal de Youtube full::scan,  twitter es una fuente inagotable de papers, noticias y autobombo que ayuda a estar al dia.

Tengo la suerte de que los clientes me llevan muy rápido al límite de lo que sé, con lo que tengo que buscar a gente que sepa más que yo y ahí es donde más aprendo.

Si miramos hacia el futuro ¿qué grandes cambios podemos esperar en los próximos 5-10 años en el mundo de Data & Analytics?

Predecir el futuro es imposible, pero yo creo que se pueden esperar evoluciones razonables:

• Habrá más DWH de Petabytes, hoy en España y Portugal se pueden contar con una mano, pero cada vez se recogen más datos de las interacciones con apps y webs y esto acabará generando cientos de DWH de Petabytes en España y Portugal.

• ML/AI permitirán la activación del dato y la proactividad de los sistemas. Todavía no creo que tengamos sistemas 100% automáticos de análisis de datos, aunque hay algunos ejemplos prometedores  de automated analytics (Gsuite Explorer, ABM,...), pero ya se podrán definir alertas de outliers o de excepciones en series temporales de una forma más fiable y útil.

• Todos entenderemos mejor en qué casos sí y en qué casos no utilizar Algoritmos para decidir y gestionar, habremos entendido mejor los límites de AI/ML y usaremos mejor las herramientas , gracias al trabajo de autores como Cathy O'Neil. Por poner algo negativo, seguiremos luchando contra los sesgos, en los proyectos y en los datasets, por suerte, espero que hayamos avanzado en conocer mejor los conceptos específicos, más allá de una representatividad muestral y que hayamos avanzado en reconocer mejor el sesgo muestral.

Y un poco “off-topic”, pero quería preguntarte sobre Bitcoin, en su dimensión de Datos y de uso de información encriptada. ¿Cuál es tu perspectiva? ¿Alguna recomendación de infraestructura para alguien que se plantee hacer mining?

No se mucho de criptomonedas, si es cierto que me preocupa el impacto en el medio ambiente de la minería de bitcoins y en general creo que se pueden buscar métodos más eficientes de firmar contratos de forma descentralizada y que no impliquen tanto consumo eléctrico. 

Recientemente entrevisté a Alejo Buxeres (Wallbox) y le pedí que hiciera una pregunta para la siguiente persona a entrevistar. Su pregunta fue: ¿Qué estrategias planteas para resolver los principales escollos a la hora de implementar una cultura data-driven en una compañía?

Muy buena pregunta, la verdad es que cambiar la cultura de una empresa es MUY complicado, por eso es importante tener un objetivo corporativo claro, un código de conducta y el siguiente paso es la selección del equipo. 

Hay gente que es data driven, les puedes reconocer porque cuando hablan te cuentan las cosas aportando datos, mencionando fuentes y si les planteas retos suelen empezar por la recogida de datos.

Puede haber gente Data-driven que no sean SWE, ni siquiera ingenieros, pero están orientados a datos antes que a opiniones. 

Se debe crear un ambiente propicio, p.e.: si alguien dice que hay un problema, tiene que demostrar el dataset, la muestra y el impacto , si vas a implicar a gente en la solución hay que tener clara la definición del problema y para eso hacen falta datos. 

Por último, si en la  selección has hecho bien, lo siguiente es poner los incentivos correctos, p.e.: antes de las reuniones preguntar por los datos o reconocer a la gente que haya hecho bien el data crunching para poder tomar una decisión. 

Y tú ¿qué pregunta le harías a la próxima persona entrevistada?

¿ Cuál es tu dataset favorito ?