The 89th episode of Datacast is my conversation with Alessya Visnjic, the CEO and co-founder of WhyLabs.
Our wide-ranging conversation touches on her education at the University of Washington studying Applied Mathematics; her 9-year stint at Amazon leading ML adoption and tooling efforts; her time as CTO-In-Residence at the Allen Institute for AI; her current journey with WhyLabs building the interface between AI and human operators; lessons learned from building an enterprise-grade AI Observability platform, developing an open-source library for data logging, identifying design partners, hiring talent, finding work-life balance; and much more.
Please enjoy my conversation with Alessya!
Listen to the show on (1) Spotify, (2) Apple Podcasts, (3) Google Podcasts, (4) TuneIn, and (5) RadioPublic
Key Takeaways
Here are the highlights from my conversation with Alessya:
On Her Upbringing
Mathematics has been my favorite subject since elementary school. That was the one thing I was good at, and my parents nurtured this interest in me by putting me in specialized math school from the 5th grade. That is when I started developing an interest in coding and mathematical problem-solving. When I moved to the US in high school, because I took so many math classes during middle school in Kazakhstan, the standard curriculum of math classes was very easy and boring for me. So my teacher suggested that I take classes at the local community college. I set a fun goal to go through the whole community college math curriculum before graduating from high school, and that was probably one of the most formative decisions. Ultimately, this laid the foundation for my professional path in engineering and machine learning.
On Studying Applied Mathematics
Like every person of my age describing their college experience in one word, I would describe it as confusing. I took a lot of computer science and math classes. I was torn at the time between being an engineer and being a mathematician: An engineering path for me was something practical and concrete that I could go and get a job after college. A mathematician’s path was something I could pursue to turn my passion into a contribution to the field. Ultimately, I graduated in 2008 with much economic uncertainty. As I evaluated my options, I chose to pursue the practical path and joined Amazon straight out of college as a very confused 20-year-old.
There were probably two formative classes I took in college:
One was a programming languages class that studied programming languages. I learned that it does not matter which languages you need to code in. Some fundamentals describe how the language works in certain aspects: How does it compile or get interpreted? How do you profile it to ensure performance? What are good code-style practices? Once you learn these generic patterns, you stop worrying about what kind of programming language you are good at. Of course, you should develop depth in a few languages, but ramping on a new language becomes easy after understanding those fundamentals.
The second was a course on climate modeling — mathematical modeling applied to climate change and climate phenomena. It was fascinating to model various phenomena mathematically and build predictive models to describe climate effects. That was when I fell in love with predictive modeling, which ultimately is what machine learning is.
On Doing DevOps and QA at Amazon
I was very fortunate to join Amazon in 2008. It was not a very popular company to join at the time. It was a fast-growing store that initially sold books, but the talent this company brought together and the rapid growth the company was experiencing was unprecedented. I joined Amazon when they were transforming all of their infrastructure and way of developing software from something not scalable to something scalable. I was lucky to witness the process that an organization undergoes to be able to deploy code daily, which sounds very basic today. Most of the time, most of the teams can embrace continuous integration and continuous deployment; but in 2008, the tools for that were lacking. It was not easy for an organization as big as Amazon (with the Amazon retail website) to go from weekly or monthly code deployments to daily.
I helped build tools around automated testing of the code (both from the UI and the performance perspectives) to evaluate things automatically. This cut down the cycle of quality assurance for the code to be pushed (from days or weeks to hours). I also worked on monitoring for latency, as to how fast the retail website pages were loading was critical to the customer experience. If you are shopping on Amazon, you definitely do not want to wait for a minute or two for a page to load. In 2008, some pages would take more than a minute to load. The fun project I worked on was instrumenting many components of the web page to see how fast or slow they were loading, monitoring for regressions (when a component goes from floating quickly to clouding slower), and tracing that change to a particular code/configuration change to understand what causes it (so we can revert or fix it).
As an engineer, it is too easy to think that you are just building software, deploying it, making sure that it checks the spec, and then repeating. If you are deploying software in environments used by others, you start realizing that there is a huge responsibility in every code line because each line can create an unpleasant customer experience. I realized that software is not just about writing well-formatted code or maybe even well-performant code, but also about how it impacts people. Plenty of software can put people’s lives at risk, so it is crucial to realize that is an aspect of your work. Learning to write robust software is a necessary mindset that I acquired during that journey.
On Becoming Amazon’s Technical Program Manager
In 2012, ML became cool again as AlexNet came out and made a big splash. Big organizations like Amazon put them under the umbrella and began to invest in internal ML groups. I met Ralf Herbrich, the director of ML at Amazon at the time. He was starting an ML R&D center in Berlin, Germany. His vision of building a team that would be the core ML function of all Amazon was contagious. I packed my bags, moved to Berlin in the summer of 2013, and became one of the first members of that team — the only Technical PM. My job was to bridge the gap between researchers and the business units. This was one of the most unique opportunities in the whole company. Not only did I get to pioneer this path of building and deploying ML applications at a company like Amazon, but also I got to live in Berlin, build my network, and meet/learn from brilliant people.
I got to essentially be in the forefront of ML adoption by internal ML teams, which gave me an opportunity to launch a forecasting platform for a quarter of all Amazon Global Retail, carry a pager for that platform, and essentially respond to mid-night calls whenever something got forecasted incorrectly. That experience allowed me to first-hand grow my appreciation for robust ML pipelines and the tools that we need to develop to ensure that they are robust. I also got to be a part of the first AWS ML service, which got deprecated fairly quickly and was replaced with Sagemaker. But it was the first attempt of AWS to have a service that focuses on ML deployment, and I got to be the founding member of the first internal ML platform, which again was probably one of the most formative experiences since I got to build the tools for all of the scientists at Amazon and helped them deploy ML solutions in a robust and responsible manner.
On Building Amazon’s Internal Machine Learning Platform
In 2015, ML platforms were not a thing as things were very much decentralized. Even in our team called Core ML, there were ultimately six sub-teams in that organization, scattered worldwide. Every sub-team had its own way of building and deploying models. We decided to start an effort in building an ML platform because we saw a lot of duplication of effort. Every team had a handful of tools for building models, deploying models, creating reproducible notebooks, keeping track of all the parameters and metadata, and keeping track of the performance and the health of the models and the data. We essentially surveyed everybody involved to understand what types of common patterns were there and what the biggest pain points were. A big surprise to me is that: in order to gain adoption for an ML platform that solves a lot of people’s problems, it requires a change in how they do their work. Instead of using your own tools that you had to build and maintain, which sounds painful, it is hard to get people to change.
Ultimately, one of the ways I drove the adoption of that platform at Amazon is by making one of the biggest pain points very easy. That pain point had nothing to do with how the model was developed. The pain point had to do with access to data. Amazon had many data sources, which were hard to get access to for many reasons: because they were in some Oracle databases, or getting access just from the perspective of being granted access to red data or orange data was challenging. The most demanded feature of our ML platform was simplified access to data. Once we made that possible, people started switching over because it would take them a lot less time to access some of the data sources they wanted to access. Ultimately, that was the main thing that drove adoption. Once people started experiencing the platform, it was an easier sell. But initially, getting people to change from how they do things to a new way is challenging, even if it is a no-brainer to you. It is not enough to show how easy it is. There has to be some kind of big incentive.
On Amazon’s Culture of Customer Obsession and Operational Excellence
Amazonians have all the leadership principles that got ingrained in their minds, and they would carry those for the rest of their professional careers. Specifically, customer obsession and operational excellence are my two favorite things that I took away. These two aspects of culture are probably the most important things that an engineer has to embrace because, ultimately, being an engineer and deploying any sort of software will have a massive impact on users and consumers. It is all about writing code, making sure the code is well-tested and well-styled, keeping up with the sprint, etc. What Amazon culture tries to instill in an engineer is that his/her work hugely impacts people and that customers have to be at the center of all decisions. When it comes to ML applications, I believe we could be better at embracing customer obsession and operational excellence by incorporating them into every decision, every line of code that we write, and every aspect of the application design we build. At the end of the day, these two things are just synonyms of responsible AI, human-centric AI, robust AI, and so on. It is just another way of talking about things that are top of mind right now in the community.
On Negotiation
Negotiations are not about winning and losing. Negotiations are about winning for both sides. It is about finding an alignment where both sides are equally happy as possible. Maybe I was just naive, and everybody knows this by the time they are in their 30s, but I always pursued negotiations as “your way of getting your way.” To me, it was surprising to learn various techniques for making sure that the person on the other side of the negotiation table will walk away very happy. I use these skills every day when talking to customers, recruiting people, and conversing with investors. The art of being able to negotiate is one of the most important skills for any entrepreneur.
On The Startup and ML Community in Seattle
I would describe the Seattle startup ecosystem as young and at the beginning of its development. It is still fairly small, but it is growing very rapidly. The Seattle ML ecosystem is probably the richest compared to any city that I have explored because of the nature of Google, Amazon, Microsoft, Facebook, and other companies having outposts and headquarters here. There is a lot of ML and data science talent. Plus, the University of Washington is a really strong school, and because of that, many enterprises decided to create ML and data science outposts here. It is a vibrant network and ecosystem of ML practitioners.
I was very fortunate to be at the right place at the right time to be able to start bringing together these practitioners because they are all in Seattle. I am an organizer of a community called Rsqrd AI, which stands for Robust and Responsible AI. That community began after I was speaking to a lot of data scientists in person over coffee. They kept mentioning to me that they did not have a community or a network, and they wished they would be able to hang out with other people who were running into the same problems that they were running in. They felt very siloed since their teams tended to be very small. So I started bringing people together — speakers from UW and guest speakers who would visit Seattle. The community started growing organically — from meeting on the roof of the Allen Institute for AI to meeting these days virtually with attendees all over the world.
What is important in community building is to bring together people who have something very concrete and common. In my case, the common denominator was bringing together ML engineers and data scientists at enterprises. They had many challenges in common, which created a natural way for topics that we would cover. Additionally, any event should have an organized component and a not-organized component from an organizational perspective. So a speaker comes in and gives a presentation, and everybody asks questions. Then hopefully, everybody is inspired with new ideas and has an extra hour to network, mingle, make friends, and develop relationships. I think any community that does these two things well is destined to be successful, and any community that’s not doing that well would probably need to improve.
On Her Time at Allen Institute for AI
My time at AI2 was hands-down the most fun job I could have ever dreamed of. I essentially spent time talking to people and prototyping. I prototyped many ML tools for explainability, bias/fairness, unit testing, monitoring, error analysis, etc. I spoke to countless ML practitioners and data science teams, who would eventually become part of the Rsqrd AI community. I also evaluated how the tools that I was prototyping were useful or not useful (which ones of them can become a software category in the future and which ones cannot). I also evaluated many ideas for commercial readiness. I prototyped hearing aids that cancel noise using deep learning, solutions for predictive maintenance of commercial real estate, approaches for demand forecasting, etc.
Ultimately, this was a year where I formulated a lot of ideas and opinions about WhyLabs. WhyLabs, the company that I am a fortunate CEO of today, was essentially developed as part of that time at AI2. Throughout my research and discussions with ML practitioners, I have identified many different opportunities in the ML toolchain that need to be their own tools and software categories. I became passionate about monitoring and observability, so I left and spun out WhyLabs in 2019.
On Founding WhyLabs
At Amazon, I had the opportunity and fortune to live a bit in the future of ML adoption since we were building the ML platform in 2015 (and ML platforms were not even a thing at the time). I had the chance to experience challenges with ML adoption that enterprises are just beginning to experience today or just began to experience in 2019. Back in Amazon, I felt that I could make a difference by leaving and making some of the approaches, tools, and knowledge accessible to every organization that was beginning to deploy ML to production. In many cases, they do not know yet that they will face many challenges with operating ML in production. Furthermore, they typically do not have access to the same resources that FAANG companies do and will not be able to build the types of tools that we built at Amazon.
Initially, it was not an entrepreneurial endeavor but rather an engineering endeavor. As an engineer, when I solved some of these problems in Amazon, I was interested in figuring out how to generalize these solutions. As an engineer, you build a solution to a specific use case and then think about how to arrive at a more generic and elegant solution. I wanted to figure out what other people do when operating ML in production. What will be the common themes from what I saw at Amazon and what happened at other organizations? How could I develop a more generic version of the tools I built at Amazon.
While at AI2, I had the fortune of talking to a lot of practitioners and kept hearing stories that were similar to my own experience. When we deployed a certain solution to production at Amazon, because of my DevOps background and tier-1 support experience, I would carry a pager that would get paged when something did not go well. Then, I would spend evenings and weekends (occasionally on holidays) trying to debug things that did not go well. Surprisingly, a lot of ML applications got derailed during holidays, especially with consumer patterns. So it was my personal pain point. But when I started talking to practitioners in various organizations, I realized they were experiencing similar issues. One of the most interesting and concrete patterns that I have identified was being able to answer a question of why something is not going right. Why is your ML model not making the predictions you expected it to make? Why are the customer experiences not aligning with your expectations?
Ultimately, that maps to the taxonomy of tools you could build for ML applications. It maps to monitoring because monitoring gives you an idea of what has changed, what is different, and what is not going right. It also maps to observability, a superset of monitoring problems. Observability gives you an idea of how to tell what is happening in your application based on the information that your application is admitting. This process of talking to practitioners and aligning their experiences with my own was the foundation of what we do today at WhyLabs.
Then, I spent some time on that engineering endeavor to figure out how to solve the problem of ML and data monitoring and came up with some ideas. I went back to my colleagues from the Amazon days who were building the ML platform with me (Sam Gracie and Andy Dang) and thought it would be incredible to have another opportunity to work with them, solving a problem that they are both passionate about as well. And we started WhyLabs.
On ML Observability
Observability is the property of a system where a human can figure out the state and the health of a system by looking at various outputs of the system. It is probably one of the most important properties of any technology because you always need to figure out how well-being the software or hardware is. One of the biggest questions on your mind (as a user or as an operator) is: “Is this working or not working?”
You can tell it by looking at various information that this technology emits: ML systems are lacking in observability because it is hard to tell whether model predictions are correct or not since models are probabilistic until you get the ground truth. It might take a while for you to get the ground truth and evaluate your models. It is challenging to tell how well models are working or not working just from an infrastructure perspective because ML systems are complex and require distributed processes and a massive amount of training data. Having observability becomes very important when you are operating them.
The second point is performing continuous data quality monitoring: ML systems can be swayed by changes in the distribution of data that they observe and the data bugs that an upstream feature pipeline can introduce. Ensuring the quality of the data that ultimately flows through inference is one of the most important activities that would help you ensure your ML system is running reliably.
The last point is keeping all stakeholders informed about the behavior of the application: This is fairly unique to ML because not just engineers, data scientists, and product managers have to understand the health of the system. The subject matter experts also do because, ultimately, ML automates certain subject matter experts’ decisions prior to the application deployment. You want to make sure that there is a suitable mechanism for disseminating the knowledge about how this application is behaving to non-technical people so that they can understand. When your model is making hundreds or thousands of predictions every minute, it is about understanding which segments of end-users are impacted (and how they are impacted) and being able to consult with subject matter experts (who would help untangle whether these impacts are what you expect or not).
On The Anatomy of An Enterprise AI Observability Platform
Observability ultimately begins with collecting the necessary information for understanding how the application is doing. Any app performance monitoring solution (like Datadog and Splunk) does this. It begins with collecting important telemetry about the health of the infrastructure. In the case of AI observability, we collect telemetry about the data that comes into the model and then the predictions that come out of the model.
Once we start collecting this telemetry, the next important task is to organize it in a database to enable easy interactive access to this data. From the telemetry perspective, given a model, we would be looking at either batches of predictions that this model makes or chunks of time (hourly). We would want to understand everything about the input features in the model and the predictions of the model. If we have any sense of actuals, we want to understand everything about the model’s performance. We collect information about the feature distributions, lineage, score distributions that the model has generated, etc. That essentially becomes a log file, which gets centralized in some kind of database. So you could say: “Tell me, what was the distribution of this particular feature in the last week or the last day or the last month? Tell me whether the accounts we have seen of the model predictions align with the number of predictions we have seen last hour, yesterday, last week, etc.” By organizing in a database, you enable this access.
Once these data points are organized in the database, you can run time series anomaly detection, which is essentially a monitoring task. Once you detect anomalies, you bubble them up to the end-users in a visualization layer and send notifications to some kind of user workflow. You display the problems that you observe to the operators so they can start root-causing and alleviating (i.e., the debugging process). This is the last component that an AI observability platform needs because once you are aware of the problem, you want to resolve it as quickly as possible.
On Data Logging
As I talked to ML practitioners and tried to understand the everyday challenges they were trying to overcome when running models in production, I heard a lot of common questions that they grappled with: How is the model performing? Should I worry about data drift? What is my training data looking like? Is the data I am seeing currently during inference very different from my training data or not? What did the input data into the model look like yesterday? These are all simple questions, but answering them is painful. You have to essentially reproduce the entire system to answer what happened yesterday. Alternatively, you have to run some complicated ETL queries, pull a ton of data, and post-process it to figure out the distribution of a few features in your model yesterday or last week.
In my experience building and deploying ML systems and traditional software, the solution to some of these problems lies in keeping track of this information. You can look back and say: “Do I have a log file that tells me what the data distribution was yesterday? I do not need to replay the whole system. I need only the log file with computed information over a meaningful window of time in order to answer my question.” In traditional systems, that is what you do with logs. If you want to understand what happened in the system yesterday, you parse the logs of the ML systems. We discovered that something as simple as logging (built specifically for ML data) could help alleviate many pain points, such as testing, monitoring, debugging, and documenting data and models.
After many years of supporting production applications in various companies, we decided that this paradigm of ML logging has to be accessible to every practitioner. So we released an open-source library called whylogs, a purpose-built ML logging library. This library provides lightweight, affordable, configurable, and mergeable data logs for both batch and streaming data workloads. Practitioners can embrace it by making the smallest change to how they do ML, essentially one line of code on your data frame that you are processing at every batch (or continuously accumulating one hour of data if you are running streaming pipelines). One simple change gives you visibility into what happened over the past X number of hours, days, and months and ultimately allows you to build essential MLOps tools (like testing, debugging, documenting, and monitoring).
On Hiring
I would summarize the lessons learned in two things: being patient and being intentional.
Being patient: A startup runs at 100 mph (or faster) and always wants things to happen fast, which does not work well for recruiting and building a team because finding the right people takes time and patience. Developing relationships early and building your network with the goal of potentially working with the people whenever they are ready to change their jobs or pursue other adventures is something that I found to work really well. I am a big networker who loves meeting people passionate about the ML tooling, ML, or robust software space. When I meet people, I never try to recruit them (although, as a CEO, I should be doing that). I rather build human connection and get a sense of what this person wants to do at some point in his/her life. In my experience, months or years later, when I met this person again, they reached out back to me as they were ready to join the startup adventure and were intentional about that decision.
Being intentional: While building an early team, you have to build a team of people passionate about solving the problem, about the customers that they are solving the problem for, and about working together. It is a big and scary rollercoaster at the end of the day. Bringing people who are intentional about joining a startup and solving this problem is what makes an incredible startup team. We certainly have that at WhyLabs, and I am incredibly fortunate to be part of that team.
On Finding Design Partners
The biggest challenge is the bureaucratic red tape around the adoption of ML tools in the enterprise. It has to do with the fact that any ML tool that gets deployed in an enterprise ultimately touches very proprietary data. If you touch the data, every organization will be very protective about their data because ML models typically run on the most proprietary data. SaaS solutions are not very common unless you do things like model lineage or hyper-parameter tuning.
After talking to over 150 data science teams, we realized that the practitioners want the tools to be more productive and struggle less with the operational aspect of ML. However, the procurement process is a mystery for them: How to bring a complex tool into the enterprise? How to get approval? Who needs to be around the table and make decisions? Many data scientists do not want to figure that out. Ultimately, after learning about this big pain point, WhyLabs decided to give practitioners monitoring tools that do not have complex deployment, do not touch proprietary data, and do not involve a complex procurement process. In order to democratize these best practices, they have to be embraced by practitioners. If they have to go through much friction to try out these tools, it will take us a long time to develop these best practices.
We approached this as an engineering problem: how to create a SaaS tool that does monitoring but does not move raw data around. whylogs allows us to do that. As an open-source library, whylogs plugs into the premise where data is running and (without moving the data around) captures all of the key statistics about the data and the model. When these statistics go to the SaaS (the deployment model), it does not require you to go through procurement red tape since the statistics do not contain any confidential, proprietary information. This removes the barriers for data scientists to try a monitoring solution, see its value, and start embracing best practices of monitoring and observability.
On Work-Life Balance
Having a child makes my work-life balance better because I cannot work all the time. I have to take care of this tiny human who is so darn cute that I cannot resist spending time with her. As I am walking this path myself — being an entrepreneur, the CEO, and a young mother, looking back at my probably very unhealthy work-life habits before my daughter was born, I would definitely spend way too much time in front of the laptop being completely obsessed with the problem at hand. Now I have a fairly healthy balance of working and spending time with my daughter, which is ultimately good for anybody. When you are unplugged and your mind is not cluttered by various information streams you are trying to process continuously, you will activate different parts of your brain. I would probably be a contrarian and recommend everybody not to worry about running a company and having babies at the same time. Ultimately, it is a very healthy thing.
Show Notes
(01:53) Alessya shared her formative experiences growing up in Kazakhstan, coming to Washington during high school, and discovering a passion and extreme aptitude for mathematics.
(04:20) Alessya described her undergraduate experience studying Applied Mathematics at the University of Washington.
(08:00) Alessya talked about impactful projects she contributed to while working as a software developer at Amazon’s quality assurance and DevOps organizations.
(12:29) Alessya went over critical responsibilities during her time as Amazon’s Technical Program Manager.
(17:06) Alessya talked about the process of building and getting adoption for an internal Machine Learning platform at Amazon.
(20:42) Alessya shared her biggest takeaways from Amazon’s culture of customer obsession and operational excellence.
(23:26) Alessya revisited her period enrolling in UW’s Master of Science in Entrepreneurship Program and highlighted two core entrepreneurial muscles developed: networking and negotiation.
(28:58) Alessya provided insights on the startup ecosystem and ML community in Seattle.
(34:47) Alessya walked through her period serving as the CTO in Residence at Allen Institute for AI and evaluating a range of AI technologies for viability and product readiness.
(37:12) Alessya shared the backstory behind the founding of WhyLabs, an AI observability platform built to enable every enterprise to run AI with certainty (read her blog post about early misadventures with AI at Amazon that inspired the incubation of WhyLabs at AI2).
(42:23) Alessya examined what makes an AI solution robust and responsible.
(46:09) Alessya dissected the anatomy of an enterprise AI Observability platform.
(49:58) Alessya explained why data logging is a critical missing component in the production ML stack and described whylogs, an open-source ML data logging library from WhyLabs.
(54:12) Alessya shared valuable hiring lessons to attract the right people who are excited about WhyLabs’ mission.
(57:03) Alessya shared tactics to find and engage contributors to whylogs.
(58:10) Alessya shared the hurdles to find the early design partners and lighthouse customers of WhyLabs.
(01:02:28) Alessya shared upcoming go-to-market initiatives that she is most excited about for WhyLabs.
(01:03:54) Alessya explained what it felt to be recognized as the CEO of the year for the Pacific Northwest startup community last year and shared her perspective on work-life balance.
(01:07:43) Closing segment.
Alessya’s Contact Info
WhyLabs’s Resources
Mentioned Content
Articles + Talks
“Introducing WhyLabs, a Leap Forward in AI Reliability” (Sep 2020)
“WhyLabs: The AI Observability Platform” (Sep 2020)
“whylogs: Embrace Data Logging Across Your ML Systems” (Sep 2020)
“Who Said Moms Can’t CEO?” (May 2021)
“The Critical Missing Component in the Production ML Stack” (May 2021)
People
Cassie Kozyrkov (Chief Decision Scientist at Google)
Dan Jeffries (Chief Evangelist at Pachyderm and Founder of AI Infrastructure Alliance)
Michael Petrochuk (Founder and CTO of WellSaid Labs)
Book
“The Hard Things About Hard Things” (by Ben Horowitz)
Notes
My conversation with Alessya was recorded back in August 2021. Since then, many things have happened at WhyLabs. I’d recommend looking at:
Exploring their new integrations with Teachable Hub, UbiOps, Valohai, and Superb AI
Launch of their listing on AWS Marketplace
Their article on How Observability Uncovers the Effects of ML Technical Debt
Their achievement of SOC 2 Type 2 certification
whylogs is evolving to a new iteration that will be even more usable and more useful than it was before. With the launch of whylogs v1 in May, users will be able to create data profiles in a fraction of the time and with a much simpler API. Additionally, WhyLabs built-in handy features such as the profile visualizer (which allows users to visualize one or multiple profiles for exploration and comparison) and constraints (which allow users to validate the quality of their data as it flows through their data pipelines).
About the show
Datacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.
Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.
Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:
If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.
