#123 Why We Need More Data Empathy

Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.

You're listening to Data Framed, a podcast by Data Camp. In this show you'll hear all the latest trends and insights in data science. Whether you're just getting started in your data career or or you're a data leader looking to scale data driven decisions in your organization, join us for in depth discussions with data and analytics leaders at the forefront of the data revolution. Let's dive right in.

Hello everyone, this is Adele, Data Science educator and evangelist at datacamp. A lot of the times it's easy for us to think about data science or even data literacy as mechanistic, a process by which data comes in and products come out. And it's an entirely physical process. But as we've explored throughout the show, succeeding in data Whether you're a data leader looking to build a data culture, a data scientist ascending the ranks, or even a policymaker looking to have an impact with data, the human side is crucial. At the heart of this human side is empathy. Empathy for your stakeholders if you're a data scientist developing a dashboard for them, empathy for your workforce if you're a data or learning leader or empathy for the planet and your citizens if you are a policymaker. So how can we all practice better empathy? Specifically, how can we all practice better data empathy? Here to answer this question is Phil Harvey, Industrial Metaverse Architect at Microsoft. Phil is a big beardy AI geek who loves working with data and solving interesting problems. He he is especially interested in soft skills for technical people and data empathy ethics and the impact of data on what people know and how they know it. Starting his career with a Bachelor of Arts in AI, he has worked in a wide range of industries from surveying to architecture to advertising to being the CTO and technical founder of a data startup. He also co wrote the book A Guide to Humans on exactly the topic we'll be discussing today. Throughout the show we talk about how he defines data empathy, the importance of data empathy in the context of organizations, how data professionals and technically oriented individuals can practice and build empathy skills how data can help solve some of the biggest challenges of our time, such as climate change and more if you enjoyed this episode, make sure to let us know by sharing it on your feed, subscribing to and liking the show and however you find useful. Now onto today's episode.

Phil, it's great to have you on the show.

Thanks for having me.

So I'm excited to chat with you about your book, the concept of data empathy, how it could help break down data silos within any organization, and how data can help us solve some of the biggest challenges of our time. But before, can you give us a bit of a background about yourself and what got you to where you are today?

I'm quite strange in that I can say that I've got 22 years in artificial intelligence because I started with a degree a Bachelor of Arts in Artificial Intelligence in the year 2000. It's a strange degree degree and a strange amount of heritage, but at that point AI was more of an academic concern. So I've worked in a wide range of industries from building an architecture 3D rendering to advertising. I was the CTO and technical founder of a data technology startup and now I work at Microsoft and my current role is an industrial metaverse architect focus on our bonsai technology. So you know a wide range of things. And yeah, the book was part of that journey because I needed to learn my way through a lot of things that I met along the way when it came to actually making data useful.

That's really great and definitely excited to parse the book and deep dive into your work. I had a pretty hard time preparing for this interview because there's definitely a lot of different angles and ways by which we can approach our conversation and discuss the book and this is usually a signal that the book is really dense with information, has a lot of richness to it. The book does a really great job at straddling between the big picture philosophical implications of developing data empathy and the practical situations where empathy or lack thereof, can really impact organizations ability to leverage data effectively. So maybe as a primer to contextualize our chat, walk us through the motivations behind the book and what led you and your co author Noelia Martinez to write it.

You're right, it's dense and wide ranging, but what we hoped to do was to find a balance between the context and some practical examples. In that way, Noelia and I are both from a technical background, but speaking for myself, I was in it. I've done most jobs in IT. I've cabled under floors, I've built machines, I've done IT support. And I was a programmer for 15 years, and people would hit me with the word empathy. Sort of hit you on the head and say, you should have more empathy, whether it's in IT support or in data or programming or those things. But nobody ever explained what it meant. I was sort of meant to know what the word meant, because normal people know that, right? And if I don't know, then I'm not normal. So I decided to go and find out, go and learn my way through it and learn what it meant. And because I'm a fan of philosophy, I went that route and went as far up the tree as I possibly could. And I found out that, yeah, data is deeply connected to a whole bunch of success with technology, success with data. You mentioned breaking down silos in that way. And I also found that empathy is not just one thing. You know, it's an area with lots of different facets and lots of different things. And so we talk about cognitive empathy as a learnable skill, because as programmers, as technical folks, everybody's on the spectrum, right? A spectrum of different neurological capabilities. And, you know, if you like machines more than people and those kind of things, and you start off thinking, maybe I'm blocked here, maybe empathy is a thing that I can't do. And so cognitive empathy was a sort of way out, a skill that you could learn, and that was the motivation to start. And then I've realized that so many aspects of what we do with data and in technology are connected to how we understand other people. And that's where cognitive empathy comes in.

That's really great. I really want to deep dive into all of the different motivations behind the book, but maybe also still setting the stage here, you mentioned here the different definitions of empathy. You mentioned cognitive empathy. You know, an important aspect of making sure that we have a productive conversation is developing a common understanding of what exists exactly, is meant by data empathy. And you do a great job of laying down the different definitions within the book. So I'd love it if you can break down that term and how it relates to the varying definitions of empathy as a whole.

So if you think empathy is at the top of the tree, what I'll do is I'll sort of work my way up from a data empathy perspective. So data empathy is a form of empathy applied to data work, and that in itself is a form of technical empathy. If you sort of go up from data work to technical work, which is under the path of the tree known as cognitive empathy empathy. Now, the difference here is we make the split between cognitive empathy and biological empathy. Biological empathy is related to things such as mirror neurons in your brain. And there are studies from animals to plants to all of these things, this thing called empathy, which is kind of built into the biological being. Cognitive empathy is a set of skills you can learn and practice and develop over time, just like any other skill. And interestingly, in the journey of the book, this is comparable to some of the things that are taught to people on the autistic spectrum, for example. So they've had some great discussions with people on that end of the spectrum about how these skills are learnable, can be taught, can be practiced, and looking at how we can grow and develop in that way. So as you see there, I've sort of split out across, you know, humans and animals and plants and these things. You also get things around organizational empathy. So I think the Harvard Business Review has a book on empathy and organizational empathy in that way. And you start to move towards user experience and understand your customer and those kind of things as well. And if you want to get complete about it, you can start to look at what's known as effective computing and artificial empathy and those kind of things which connects most immediately with the ideas of agents that communicate. So you could say chatbots and virtual agents and those kind of things. So that's the sort of big picture that we go through. But the book really focuses down into data work because data is this incredibly valuable asset that we now have available. And empathy can make you more successful in your data work and in a.

Lot of ways as well. You mentioned here, kind of artificial empathy data also powers a lot of tools that interact with different stakeholders. So also embedding that quality within the development process is highly important to create successful experiences, but also safe and rich experiences using data products.

That's right. So data can give us new things to know and new ways of knowing it and to do that safely with understanding and all of those things. This is what we mean when we talk about empathy will make you more successful. You need to understand your stakeholders. You need to understand the point and the value of the work that you're doing. If you're really going to connect the dots with the data work to really bring that value out, that understanding is a key part of it.

So I'd love to contextualize this conversation. You know, as you mentioned in the organizational empathy side, specifically to data work, and you mentioned here that Cognitive empathy is a learnable skill. I'd love if you could provide an example of data empathy in action within an organization, specifically on how this skill can be learned.

So the learning part is one of the most fascinating parts of the journey and I'll dwell on that for a little bit. Learning is about practicing. Nobody came out of school being a great Python programmer. If you're a Python programmer and you want to do a job working in R, you need to learn R, you need to practise it. You don't just read a book and that's it. You need to develop the muscle, you need to practice, you need to spend time. Cognitive empathy is just like that. And you can practise in a load of different ways. The first way is in your work directly, and I'll talk about some specific examples there. But you can also practise with media, entertainment, films, music, art, all of these things, because you start to engage with it as a form of practice. So if you go into an art gallery, if it's not something you've done recently, I'd encourage you to go and ask yourself to look at the pictures as if they relate to your data work. It may sound like a strange thing to do, but look at a picture and go, what does this show me? What does this tell me? Under what conditions was it produced? How was it produced? What can I learn about it? Open yourself up and question in that way, when it comes to your work, let's take some specific examples of something as simple as producing a dashboard. So you're going to get a set of data, you're going to process it in some way, something everybody who's listening has probably met at some point, and then you're going to need to show it to somebody. You can sit down, you can take a ticket off your work system, you can do the coding and do the work and then show it to somebody. And loads of people do that and they get very grumpy about the feedback and they think the people who receive the work don't understand them. That is not practicing empathy, that is not thinking about the work in the broader context. In that case, you've got to think about the audience, what questions you can ask them, what opportunities you have to listen to them to understand the context that your work is going into. So that can be everything from the topic, terminology. So let's say you work in a centralized data department and the dashboard is for the sales team. You may think the sales team have no technical understanding at all, but actually the sales team bring the money into the organization. They pay for your salary, they pay for your work by getting customers to engage the organization. They'll have a language, they'll have a way of learning, they'll have a way of doing their job. Your dashboard will need to fit into that way of doing the job. This may sound obvious to some people, I hope it does. But the number of failures in these particular things, they use the wrong colours, they use the wrong terminology, they present something in too technical a fashion, the lists are too long, the charts are confusing, they could simplify down to a single example of next best action, as opposed to giving people 100 options. All of these kind of experiential pieces. If you practice your data empathy, if you develop the skills of listening and questioning and those things, it means that your work will be more quickly accepted. It means that you'll have a more satisfying experience delivering that product of work. And it also means that you'll get asked to do more work. And more work is good because we all got to keep our jobs.

That's really great. I love the example of the dashboard and in a lot of ways it seems like a lot of these problems, and correct me if I'm wrong, can be alleviated with a checklist or systematized approach in incorporating empathy within the creation of data products. I feel like a lot of data folks, you know, tend to be systems oriented people naturally.

Right.

And there's a way, as you mentioned here, kind of to bridge the gap in learning empathy by incorporating the systems oriented approach in developing data products. Would you agree that that's the case and have you seen that in action?

I'm slightly wary of checklists. While I totally agree with what you're saying in principle, I think I don't want the listeners, for example, to go away and say, oh, create a checklist and that is empathy and we're done. The process of listening needs to be built in. So if you've got a list of work that you're doing, if you haven't included some aspect of listening, then you're not going to do as well. That's the kind of core skill to it, the systems thinking approach. What we provide in the book is a model of how cognitive empathy breaks down, a model of what you're listening for, the paradigm of your users. Now that can generate a really useful list, a really useful set to make sure you've covered everything. And it could be how they learn their epistemology, it could be how they do things, their methodology, the way they describe their world. In their ontology all the way through to the ethical concerns and the aesthetics of how the dashboard can look. And so breaking down the system of listening, breaking down the system of the stakeholders is really key. And yes, just as you say, this can be easily written out as a worksheet or a list of things you do, but the list is not the point. The list is only the way that you make sure you've covered everything.

The most important aspect is the conversation, is the listening aspect between the different stakeholders involved in the creation of the data product. Would you agree with that?

Yeah. Listening is something everybody will always hear me coming back to because it's the core number one skill. It's the best way of practicing, practicing. It's the best way of getting information. In the book we break down a whole bunch of other methods within that. One of my favourite ones, and I use this all the time, is being brave enough to be wrong. People tell you so much more if you say the wrong thing because they want to correct you than if you go in trying to be right. So while it is all about encouraging them to speak and so you can listen, actually practicing the skill of being wrong to generate information is incredibly valuable. So we go into that in the book as well. But it's that it all comes down to you've got to be open to listen. And the cognitive empathy model gives you things to listen for, so it makes it easier to practice.

That's really great. So kind of on the theme of here, listening, kind of creating that two way conversation. An incredibly important part of developing data empathy is recognizing who is in fact uses data and how.

Right.

As you mentioned in the book, you outline kind of two common Personas who interact with data, data producers and data consumers. Walk us through how you define these profiles. What are the typical roles that occupy these Personas? And how do you imagine a productive conversation where empathy is displayed between these two types of Personas?

So I'll switch my examples to a much more technical set of Personas. In this case, when you're producing products in the data space, that could be the dashboard, it could be an API, it could be a data file. So a data engineer providing a data file to a data scientist in some kind of cloud storage. It could be a database, database administrator, or it could be somebody from the market research side gathering data, producing questionnaires and those kind of things. At each point in that journey, there's going to be a producer and there's going to be a consumer. The producer is providing a product or service to the consumer. And the consumer is receiving that product or service. Hopefully that's crystal clear. I can't think of how to break it down further there. You've got to identify which one of those two you are, because it's easy to accidentally fall into consumer type thinking when you're the producer. And it's really easy to think as a producer, especially if you're technical, when you're actually in the consumer role. So if you find yourself going things like, why have they done it like this? I do it differently. I don't like the way this API is formed, or I don't like the structure of this file. I would have used a different file format. You're using producer thinking as a consumer. Actually it can be much more helpful to go, I'm the consumer, the producer is providing this product to me. And if I think about why they're doing it from their perspective as the producer, you'll find much more productive ways into getting the changes that you want to have.

Maybe walk us through an example of how you've seen that shift actually produce the desired change. Maybe, for example, in an example that you've seen, or, you know, a hypothetical example.

There was a particular phase of the big data journey around APIs and accessing data. It's a very different world now, but we were consuming social media APIs. We were producing essentially an email product at the end of it for downstream consumers, for our stakeholders. There are two examples that those different junctions. So when we're the consumer of the APIs, we had testing in place, we had robust connectors, we were consuming, we were being good consumers of that API. And then the producer gave us completely arbitrary numbers. All the testing passed, everything looked fine on our side, but the numbers were actually wrong. I can't name the company, but one of the social media providers at that point. And so what we produced downstream was wrong and obviously wrong. And the customer saw it. And we're like, all the lights were green, all the testing works, all the pipelines worked, all that kind of stuff. But what it led to was us digging into the terms and conditions and the documentation to find out why they could produce the wrong numbers and not consider it a problem. Why did we get these numbers, which were so obviously wrong, out of that API? The reason was because in the documentation, they provided no guarantees that they promised corrections. So if we raised a support request, they would look into it and they would correct it. So they promised corrections, they didn't promise correct numbers, guarantees. And so that is a specific example. You go it's easy to be cross about that than to stamp your feet on these things. But we had to find a way in. In that case, it was finding the right documentation. It was an entirely non technical solution. It was a bit of reading, a bit of tracing to understand how we could protect ourselves, because we then had to implement things to protect ourselves from the way they were producing. Similarly, on the other side, on the email dashboard side, the customer, the consumer of our data product told us clearly, they wrote down, they made it very clear in a number of meetings that all of the data for producing the dashboard was in these files. Again, I'm being slightly general just to protect the innocent. They came in via emails, we processed them and these things. But every time we sent a sample for checking with the end users, they tell us it was wrong. So we dug and we dug, we checked the files, we double checked all the technical work, but it turns out that they were gatekeeping where the information came from. There was a key figure which was dealt with in a phone call between somebody senior and somebody on the downstream side of us, which meant the numbers were not in the data, not in the files, not in these things. And again, all the technical work was right. We wasted a lot of time checking. But what we didn't do was truly understand the context. And when we found it out, we could trace back all the things that we missed, all the gatekeeping, the people who didn't like the fact that this work was being done, the people who were sort of protecting their own role and job and those kind of things. And all the signs were there. We didn't listen properly, we went straight for the technical work. And every time we told it's wrong, we checked the technical work, we didn't check the people.

I think this is an amazing example of really the importance of developing not just empathy between the producers and the consumers, as you laid out in the techno classic, but also trying to understand the human context and the business context in the setting around the development of a project. And I think the segues pretty well to my next question and kind of the other theme that I want to cover, which is how data empathy really can power also a data culture. One of the main themes that we talk about here on the podcast is the importance of developing a data culture. And really a key hallmark of that is honest context setting, being able to understand the impact of data and how it can be used effectively by everyone within the organization. So maybe walk us through, how does data empathy intersect with data culture and, and kind of the Imperative for organizations to develop and drive data skills and data literacy within the organization.

I like this question because the answer is simple. In data, there's a lot of complexity to deal with. Data empathy is a core skill in a data culture because it is a skill around understanding, understanding different people, understanding different roles and all of those things. So I would say that that is one of the fundamental reasons that we worked on the book was that you're not going to get cultural change unless people have the skills for listening.

That's really wonderful. And maybe walk us through, how does data literacy here and the skill set play into the data empathy component as well?

Data literacy is a wonderful weapon as a term within data cultures. And one of the areas that we explore in the book is known as socio technical blindness. Of course, our data work is not successful because marketing just have poor data literacy. Of course the IT department don't understand us. They keep telling us to improve our data literacy, but they just don't listen to us. In that you have the words being used as a weapon by group to group communication. Marketing is not a thing. It is a collection of people under a title. Yes, data literacy is important. Making decisions based on data. You need to understand how to read and understand data. But if you find in the language, you're using the term as a weapon, much like I was hit with the term empathy earlier in my career, the same thing happens. So when you find yourself saying that what you have to do is to understand the people and understand before you start demanding data literacy what that would mean, there's work to be done, there's a bridge to be built there.

I really love that perspective because oftentimes we've seen this at datacamp, we work with quite a few customers on upskilling and data culture projects. One of the key messages that we always try to say is that the importance of data skills and scaling. Data literacy is an enabler to create a common data language and enabler to create a common language. But it's not meant to be used to punish or to group. And I find that perspective very aligned with that. Because one thing that we found can be harmful, as you say here, is that data literacy can be used as a weapon to let go of the kind of onus or the responsibility of making sure that the data product that you're developing, for example, is accepted right and is useful for the data consumer. What do you think are ways data teams or data leaders, for example, can avoid this trap and are able to ensure that their data products and whatever they Produce for the rest of the organization is useful and can continuously accept regardless of the data skill set of the organization.

So this comes to the more let's call it enterprise technical language. When you're looking at that data culture from the roles and the team that you have now. I talk about people practicing cognitive empathy, data empathy, technical empathy, all of these things, it is right and correct that in some people's roles it's not appropriate. They may be your best Python developer and actually them spending time with people is less valuable. What that means is you need some role which is a bridge between the non technical and technical people. Yes, empathy will make everybody more successful, but in a team, in an enterprise scenario, when you're looking at your culture, you can look at evolving roles to become more bridges. So one data team that I worked with, we did a sort of day and a half's worth of workshops from a data empathy perspective. One of their data scientists worked with their manager to change to become a data architect. And the architect's title as an evolution of the data scientist was a useful change to allow them to be the bridge. They were there to support the more, let's say focused data scientists to spend more time with their code and they were there to support the less technical people outside of the data science team to communicate effectively. They were a bridging role and that's the kind of concrete change that you can make. And people find huge productivity gains in their data work there because there is somebody who's tasked with that the socio technical role, as it were.

I love that the data architect or translator role as an important lever within the organization that can facilitate data empathy. An additional thing while reading the book that popped out to me is that outside of these role changes organizations can make is the importance of context setting. So the ability to discover metrics, data definitions, documentation you mentioned here the documentation example to be able to understand the different components that go into a data product to be able to find data, to work with data. How important do you find such kind of tools or components of a data strategy or data culture in developing and facilitating data empathy?

So that I'll stick to the word data strategy you used there documentation, standards, communication, data dictionaries, all of these things are key parts of your data strategy which intersect with your data culture. As we've been discussing there, standards is a great example because you can find lots of problems of standards implemented incorrectly. You know the N1 standards example documentation I'll dwell on just for a second here because if you're ever wanting to do. If anybody who's listening is ever wanting to do some super interesting research from a cognitive empathy perspective, go and look at the documentation of a data product API database, whichever it is, from the perspective of understanding the people who produced it. You'll find signs of boredom, you'll find signs of bad automation, you'll find the language that they use, the mental models for building that particular data product and all of these things. But you're doing a sort of meta reading of that documentation. You're not just going, oh, I can't find the thing that I want. You're building and understanding the product from a different perspective because that text has put something of the data producer out there. So standards and documentation would be the two that I'd call out that you need to build into your data strategy because they will support your data culture.

Completely agree there. That's the power of documentation. And being able to just level the playing field across the different functions that are interacting with data is extremely important. Another thing that's really interesting in the book, that especially the appendix covers a lot of different practical examples of data and empathy and how they play out in action in organizations. I'd love to pin the conversation here and ground the discussion in a few examples to showcase really the power of data empathy. Walk us through your favorite examples from the appendix and how you've seen them play out in your career.

Thank you for raising the appendices. We structured the book in quite a strange way that it's actually a game of two halves. The first half is the theory, the second half is the examples in the appendices. And the final appendix is a method called Data Landscaping, which is a soft tool which would be interesting there. My current favorite example, very specifically, which we cover in the book from a data quality perspective, but I want to expand on that. Data quality is this really fascinating conversation at the moment from a data empathy perspective because we've had enough years of data scientists now for implications and ramifications of data science in the workplace to start to bubble up. And that was a survey that I won't mention that I got to discuss with the people analyzing the results. And the most interesting one for me is that data quality has become a C level issue within an organization. So CEO, cxo, whoever you want to talk about, says that their organization has a data quality issue, but that's not true. That is a ramification of the fact that they hired expensive PhD level data scientists who couldn't do the things they thought they were going to do. And the easiest thing to blame is that data quality, because they couldn't get what they wanted. And the easiest way to express that is the data is of poor quality. Actually, no data is of quality unless you've already done the work. So you'll find high quality data for a piece of work if the piece of work has been done or tried before. That's the only situation where everything will fit together well. Because that data quality work is, is and still is and always will be the majority of the work of any interesting project. Because the interesting projects is where you're bringing things together which weren't brought together before. And whenever you're doing that, you're going to hit producer, consumer issues, product issues, all of those kind of things. So when you work through what a data quality issue is, you find lots of examples where cognitive empathy and data empathy will really help you because you'll identify that. That this field was aggregated by month because somebody who ran the database at that point couldn't get the budget to get more storage for that database. So they had to reduce the size of a table in some way. And the way they did it was aggregate into a field. So it shortened the table and dump out the actual data to a log or a file. Turns out they thought it would persist, but it was cleaned up by an archiving process. There you go, data quality issue. Loads of people involved in that.

Yeah, that's a great example. So in a lot of ways, trying to make sure I got the best insight here is in the data quality example that you mentioned here. Definitely. A lot of organizations have done massive investments in getting like, PhD level data scientists who are machine learning experts, without necessarily having the foundations set up first, without having necessarily paid attention to the process of turning data into valuable assets that can be then transformed with the skill set of those PhD level data scientists. And that in a root cause, is a data empathy problem. Would you say that that's an accurate summarization of the stance?

Yeah, that's a great summary. Quite often it's not even as clearly played out as you described there, that the data scientists will be excited to do the work. They'll pitch themselves and their experience and their skill to the organization. The organisation will say, yeah, we've got loads of data, loads and loads of data. Yeah, we're really keen to get the best out of it. Really want to do some machine learning. And then what you say will play out. The foundation isn't there. The data scientist goes, but now I have to do all the boring and hard Stuff that I really didn't want to. That's the reason I left my last job, because their data was a mess and I spent all my time tidying it up and not doing machine learning. It's the same here. So the questions you asked during the interview are how many data engineers do you have? How many will I have on my team who will be there to support me? Me doing that didn't ask any of those questions.

And that's at the root cause a lack of empathy, lack of understanding and a listening conversation component. That's a really great insight. Now you mentioned as well earlier in our conversation how data and data empathy can really help us solve some of the biggest problems that we face as a species. You mentioned climate crisis for example. Walk us through maybe your thoughts here and how you think data empathy solves or alleviates these types of challenges.

Thank you for bringing us onto this because the climate emergency is a one top priority and should be for everybod body. And this is something one of the reasons I partnered with Dr. Noelio in writing the book as she has such a fantastic perspective on these challenges. Now, data is this asset that we have, is an informational resource. It's in the space of what we know. So I've said data, information and knowledge in the same sentence. You know, there's a lot of pieces to that puzzle to philosophically unpack, but you're looking for what data can tell us. And when you're looking at Earth system science, when you're looking at the impact that you have on any, you can look at that from an individual perspective, you can look at that from an organizational perspective, you can look at that from a societal perspective, you can start to look at the systems and impact and processes of the planet, of biodiversity, of all of these things. You can go back in history into the 70s and you can find the World3 model, which was a system dynamics model, was based on distributions developed from the data and understanding of the climate impact of hydrocarbons and society at that point. It has been proved accurate to this day. A piece of modeling from the 70s, people who understand how to process data, understand how to look to the root causes of the challenges that we face. You can understand biodiversity from incredible different angles from satellite images, from testing water at mass scale. You can gather data on almost anything that you want, model it, work with it and learn something on, you can take action. And that's the key piece, whether it's in business, whether it's personally, whether it's for the climate emergency or Biodiversity or any of those pieces. The data is about driving action. Just knowing is not enough. We can go to Buddhism as we want, where wisdom and action are the same thing. That's where you've got to start thinking about that. How clean is the cloud that you use to process the data at work? There is a way of finding out, there is a way of listening to the system which you're in. The system of people, the system of the environment, the system of the world.

That's really great. And I want to go on, maybe have a bit of a tangent here and kind of discuss the different dynamics of how to create a message that drives empathy. You mentioned here the climate crisis, a large portion of why there's inaction on the climate crisis is a bit of a messaging problem around the climate crisis. Do you think that there is a case to say that to drive empathy within people? There's the Paul Bloom book on Against Empathy where he describes the distinction between driving empathy with statistics and with data versus driving empathy with stories, and that stories in themselves are much more personal, they drive action much more. Do you find that distinction holds when having a conversation around something like the climate crisis and how that plays out?

Yes, I really enjoy Paul Bloom's book and I think just before digging into that topic, the key cor out of the spotlight effect of emotional empathy is a really interesting part of Bloom's theories and it also relates to what you're saying, that the stories can have that problem as well. And when you're looking at the full scope of what empathy can do, just like any other tool that we develop, any other skill that we have, you can use it on a specific spectrum of good things to bad things, as it were. So stories are great at driving emotion. If you've ever had a film make you cry, all those things, or if you ever switched channels because the charity advert was just too hard to take in that, say, then that's the story tugging on your emotional empathy, cognitive empathy. And some people talk about rational compassion on this aspect, which, you know, statistics, data and information on that end, it doesn't feel the same. It doesn't tug on your emotions, it doesn't create that spotlight effect. So I'd say that while it's easy to say it's a blend of each of them, if you understand that spectrum and you understand what you're trying to do, yes, a story will help you at one point, statistics will help you at another point. And the fact that you raise those different points is incredibly important because I'm talking about cognitive empathy as a learnable skill skill. It won't make you a super person, right? You're not going to suddenly your head's not going to light up like a light bulb and you'll be able to fly, but it gives you a tool to use, just like Python, just like storytelling and all of those things. So I totally agree that storytelling is a massively important skill, but it's not the only skill.

Completely agree there. So as we wrap up, I know that we're reaching end of time. I'd be remiss not to also talk about where data empathy fits into the conversation with the rise of really robust generative models such as ChatG, Dall? E2 and more. Something you talk about in the book is that artificial intelligence has the potential to free us from drudgery and elevate our quality of life and work. And additionally you mentioned that the road to these technologies, the road to that time and place where we are freed from drudgery, will be turbulent as we grapple with these technologies. How do you see the next few years playing out with generative AI? How do you anticipate data empathy or our applications of it changing and evolving with the advent of these technologies?

Huge, huge topic. So there are loads of aspects to the way that these models can be used. Let's talk about language for a second as one of the focus pieces in that you just mentioned storytelling and the emotional manipulation possible within language and storytelling and those things. However, language as a data set is fascinating because language doesn't carry meaning. Language causes meaning in a mind. And so if you use it, expecting it to carry meaning and that to lead to emergent magic properties of AI systems, then you're going to fall foul of a whole bunch of different problems. Now, in the development of these models, we Talked about the PhD level data scientist who's great at machine learning and all these things. You can track that back to the way that PhDs are trained in academic scenarios. And you can find in the AI conversation a whole set of aspects where empathy will really help understanding the impact of these tools. If you take Dall? E, for example, there is a conversation burning at the moment around this was trained off images on the Internet. If you're looking at style transfer, a lot of the images that were used to generate the ability to do style transfer in that way belong to artists who shared them under a particular consideration. In that way, there are people behind all of this, right? So developing skills to understand people's paradigms and those things will play A key role in how AI develops. It will even play a key role in how AI interacts with us, because our paradigm is not in the data we leave behind, it's within us. So being able to model that in a different way is incredibly important. And so it's a really huge topic. We can cover it from the perspective of how AI will change over time. But I really want to bring it back to the idea that people will be working on this. Hopefully somebody who's listening will be working on an exciting AI project and they may go, where did we get that data from? Why am I so frustrated about this thing? How are we going to deliver it to that set of stakeholders who don't understand how it works but want to see the value out of out of it? That's the thing that really matters to me, that we can talk in length of all the grand different topics, but it comes down to the people. Who are you going to listen to next? Whether it's data, whether it's dashboarding, whether it's machine learning, or whether it's AI.

That's really awesome. There's definitely another episode in the making here to discuss all of these topics. Finally, Phil, before we wrap up, do you have any final call to action before we wrap up today's episode?

Well, I'd obviously love it if people were interested enough to read the books, so thank you. But please understand that empathy will make you more successful. If you're not working or doing any data work to be successful, fine, carry on as you are. But if you're looking for success in that work, skills in cognitive empathy will help you be more successful. We go into great detail in the book about how that happens. You know, we don't leave it as a statement, we unpack it. The main way to do that core thing that you're going to need to learn to do do is to listen. And that's where I want to leave it. Everybody just starts listening a little bit more. Amazing.

That is awesome. Thank you so much, Phil, for coming on Data Framed.

Thank you. Great to be on.

You've been listening to Data Framed, a podcast by Data Camp. Keep connected with us by subscribing to the show in your favorite podcast player. Please give us a rating, leave a comment and share episodes you love. That helps us keep delivering insights into all things data. Thanks for listening. Until next time.