 That was really my first immersion into the deep end of storytelling because you have to take them from the universe estimation methodology into the measurement methods that you or approaches that you've used and convince them that this is actually what the market looks like, and this is a number of table tops in the country, this is how much gum Gypsy fruit they're selling. And so, over time, I became conversant with how the framing of those stories needs to look like, but even more importantly, at the back of my mind, I always know that no matter how good the analysis is, for as long as the story you're telling is not good enough, and you risk losing everything that you've worked so hard for. And that sets the stage for the next 30 or so minutes of this keynote. Inherently, we are all storytellers, even beings. They say that you're alive, we live in a network of stories, and that there is no stronger connection between people than in storytelling. One of the writers that you'd like, who's a brilliant sapiens even says that stories and gossip are the reason we are where we are. So at the end of the day, in whatever field you're working with, storytelling becomes the connection between everything very technical, and that actually being impactful or making sense, and driving the value that you envision it to drive. That's the first point storytelling is important. So let's park. The second one is data science is simple incomes of how you think of the framework within which you do data analysis and data science at large, because you told collective data. You can do surveys through writing as well, code, or whatever, and then, you know, analyze it and then present it, right, very simple, but it's hard. All of us who've worked in this industry who are getting into it who will be studying it know that it's hard because it needs you to understand the business problem and the context is it a product that you're trying to build so on data to collect how does that product look like work with different stakeholders, and if it's KPIs, then this vary across the organization. What are the most important metrics for X score, the executive community that is what are the most important metrics for the operational teams the functional businesses, then you have to go and get that data. And that could be through surveys or it could be through writing and SQL or even getting different spreadsheets we have a lot of companies that still have spreadsheets as their databases or a mixture of all that. Then you get into the process of cleaning and exploring when you do that time and time again. The cliche within the industry is that 80% of the work of data science and data analysis is actually doing that. And there's a lot of truth to that is a lot of truth to that. You build your dashboards or you build your models and then call it dead them and then there's a whole very technical cycle of figuring out what the best visualization techniques are, what the best models are. How do you present that is it through an open source tool is it through a PowerPoint like this is it through a BI platform when you deploy and and I'm obviously trivializing it, even by saying that because of how much work, the amount of work. The insurmountable amount of work that goes into that, but all that does not really matter unless you can get the output or the result or all that toiling into being useful or valuable or being impactful depending on what you're looking at, if it's a business scenario, operational scenario, even in not for profit organization then impact is very, very important. Is it a product or are you measuring the impact of that product? So you could do all that spend days, weeks, months, even a year building something and because of how you package it, then it turns up not becoming successful. That's a significant percentage of beta science projects fail. Let's have a look at, let's start getting into some of the reasons why some of these solutions end up not becoming useful. They're not entirely useless, so I will stay away from using that word, but they're not very useful. And that is what we all want to be, we want our work to be useful. The first gap that is related to storytelling is you being able to not ask, we being unable to ask and answer the right questions. And you could be asking whatever questions you ask and answering them very well, but for as long as they are the wrong questions, then it really does not matter. There is an art and a skill to this and I will go into the depth of it. Socratic methods and so many other ways of you being able to frame your questions. Now if you're not able to ask the right questions, then it means that a couple of things happen. One is that you end up using an approach that could be methodologically correct, but is answering the wrong question. Then you get into this rabbit hole or loop that you do not really want to be in where you have to answer particular questions spend so much time doing that. I mean then having to start all over again when you realize oh snap that was the wrong question. Right. I found myself in such scenarios and I think to some extent, I'm guessing a lot of us have done that, as you perfect our art or asking the right questions. The main thing here is one of the things that works is, you know, do not shy away from asking as much as it's hardly possible prior to starting out whatever you're doing. So if this is something that is led by particular functions or particular people in the organization, then you want as they are making that request or giving you these ideas about what they want. Is it a model, is it adaptable, is it a report, then you want to ask as many questions as possible, and keep going back to them at that initial phase. If it's you who's driving, they saw each an innovation, for instance, that you think would be useful to the business. Then over and above doing the things that you should be doing such as, you know, rolling out a pilot or a proof of concept, you want to ensure that you are getting as much feedback as possible from the stakeholders and the people who will actually make your new innovation, your product, whatever you're doing successfully. What metrics should you be looking at, are they exhaustive or you calculate those metrics, how do you define success because you could be defining success very differently from how they're defining it. And then listen, I do not think I need to speak a lot about that. By now, all of us should know the importance of listening as data analysts because of how imperative it is to storytelling. The other thing that I found to be very useful is, besides being from very early on, especially for analytics projects on whether you want to use either the hypothetical approach or the exploratory approach. Both of them have their pros and their pros. So you have to be very clear on have a lot of clarity on what you're looking for and what you can stand, what you can afford to lose depending on the methodology that you use. So when you go hypothetical, it means that you're limiting yourself from answering a lot of the other questions that exploration would give you answers to. And when you're doing exploration, one of the things that you lose is the component of especially time because you end up looking at the data slicing, analyzing it, analyzing it in so many different ways because you don't have a question that you're asking. It's good for different projects where no one knows anything. So, you know, go in there and tell me how customers are behaving. I don't have a hypothesis about how our customers are behaving. I don't have a hypothesis about how things are changing over time around our different products. And then on the hypothesis side, you could say, okay, there's been a reduction in metric X because of why that is my hypothesis, can you get it to the written prove it. And so when you're having this early engagement, you must be very sure that even that hypothesis is very well defined and aligned with the different stakeholders. So that's one, I'm asking the wrong questions. And one is weak stakeholder buying which is slightly related. There's guaranteed failure no matter how good your work is, if you do not have the right stakeholder support. We always say that for instance for innovation project find a sponsor, find someone who is higher up in the organization if you're not. Who's an ex-co in the leadership team, a functional leader who's very attached to whatever you're doing to drive that for you. Functional and executive leadership must have a significant level of belief in the purpose and the value of what you're doing. And the only way you get there is by sort of creating that picture of how the results would look like. Do not again spring things up on them. Do not just, you know, appear and send an email for instance and say, oh, we found this and this and this and this is what we're doing about it. Without any context whatsoever. If it's an innovation if it's, you know, new metrics that you're rolling out then you're thinking of rolling out and testing, then you must think of it as a product manager for instance. So, one of the things here that I've done, I've seen a lot is new learning from the product managers within organizations and also thinking of itself as an analytics product manager where you create roadmaps. For instance, for the work that you're doing and help them and sorry ask them for help, because a lot of them are willing to help you and in the very few cases when you don't have to build something together then whatever you've learned from them is applicable into your different projects, but you don't have that clear roadmap at what point do you inform stakeholder A stakeholder B a function leader, at what point are you pushing out these different metrics at what point do you want to test that out with a group of users if it's a product and so on and so forth. But that ensures the stakeholder buying. If not then you're guaranteed to fail. The last one that I think a lot about is the fact that we end up creating a lot of unnecessary complexity and complications and those two tend to be quite different. Now, the structures and behavior of different phenomena is already complex as it is, especially in this day of interconnectedness and a lot of software driving different things and different decisions. So, as an analyst as a data scientist, it's not in your best interest whatsoever to increase the level of complexity and the level of complication within any particular project that you're working on especially at that latter stage of communicating and storytelling and driving impact on the other downstream. And there are different ways you can do this. I mean, first of all, a lot of the problems you really need to be honest here. They have a certain degree of complexity and complication but they tend to be mostly either known or knowable, meaning that the course and effect are perceivable, they're understood, they can be understood, and if not directly perceivable then the separation is across time and space. That's one. And the different techniques of reducing that complexity from a philosophical point of view, when you spend complex systems, you know, you could use homogenization techniques, abstraction, transformation, and so many other things that ensure that as you proceed, even if the techniques you're using are complex, then complex within that system because that's what they need to be, then they're not adding another layer of complexity, they're rather breaking that structure or that behavior pattern down. That's one. And downstream when you're communicating, make sure that you make it as simple as possible and focus on the rules that matter. That's one too. We have a tendency of using data science techniques as hammers and every single problem that we have is a nail especially, you know, for instance, deep learning. It's amazing for different reasons. But in a lot of problems, many of the problems that we are working on, then we do not need to make them to use such advanced techniques, just because we know them, we have the tools and we do not need to, you know, build a GPT3 on your next sales prediction or a GPT3 on whatever question that you've been asked by the head of operations, right? So don't make it complex by using these complex methods or complicated methods or that are hard for people to understand, interpret, and so on. Again, make sure of predictability. When we do not do that, then it makes it hard for us to go back and tweak things, change different things, and that's why, for instance, I is beautiful for this. And there are a lot of resources that enable you to make sure of predictability within the projects. Always remember that the major success is not how accurate your model is, not how sleek your dashboard is. It's on the business and operation sites. So if they're not able to, the users, the end users are not able to make decisions and get insights. If your product is not able to meet certain metrics that the organization has put, then you're not successful with respect to how sleek, how elegant the underlying model or underlying analysis is. Okay, so we laid down all those different problems and there are many. Those are just but a few that I've encountered and the few that I think have been possible for sources of friction and the performance of different projects that I've carried out. And we can also brainstorm on a few at the end of this. So with that background, I want to share two ideas around how we ensure that we use storytelling or we can ensure that storytelling is beneficial to us and actually is a net positive and not a net negative in terms of making our projects successful, successful, valuable. The first one is understanding the audience and that's quite simple, but there are a couple of things that I want to share today. The first thing is why do we communicate. Communication has different reasons, three of them that have been shown to be very important across organizations are, you know, direction providing direction. An example of this could be a that we need to make these additions to this dashboard or, you know, to this model to do this and this and this and this is maybe you as a leader or a manager, talking to the people who are uniquely in that direction. And the communication needs to have all the clarity around why are we doing that. Why is it important. And even sometimes go as far as saying, okay, I have an idea about how we should do that or, you know, here are some ideas, rough ideas that I'm thinking about, can you go research more, and then come to come back to me, and then we can make those adjustments that's one to its inform. This is when you're relaying information about different findings, different insights and stopping at that. So it's telling, you know, your sales people or your head of sales, your commercial director, that we are at risk of using 8% of our customers in the next month in the region, because of the increasing levels of out of stock in the different shops. You know, that's an example, you informed them after doing some analysis that gives you these insights. And then the last one is to pursue it where you're now going beyond just performing and telling them and actually having a point of view yourself in terms of what should be done and using different persuasion on the techniques to make to bring to make them actually do something about and not just see things in a particular way, but actually take steps towards doing something about that insight. So we've noticed in this problem, we should send personalized message to customers in the MITRE and offer 5% discounts to reduce the risk to 3% from 8% and this is an analysis that has gone into me making that recommendation. And that needs to be very, very clear. Now, the preface to that is that you must be able to understand your audience and be have clarity on what communication needs to go out then is it direction, is it informative, informational, is it persuasion. All audiences that you might be communicating to mostly similar in that one. All our minds as human beings as I started out by saying, our story processes and not logic processes meaning that we function better. We consume information better as stories and not as logic. That's one to we respond most strongly to stories that have a sort of pattern to them. They have a general structure. The hero, the hero story, for instance, when it starts out with a conflict, and that conflict leads into some sort of tension, and then within that tension, their characters who are either on the good or the bad side as a hero, and then the hero transforms. If you look at all the movies across time. That's sort of the structure that they follow because research has shown that that is a structure that human, the human mind, mostly responds strongly to. How do you tailor in your communication history telling in the same way you don't need to reinvent and just fitting in that particular structure. That's one. Only all audiences that you talk to all people will be similar in that they want to participate in stories based on a couple of things one of them is engagement and engagement here is not just about people paying attention. It's about them having some emotional investment that comes with that attention. So it's not just people paying attention you want as well to evoke something out of them. That's what engagement is. It's been shown around storytelling that's one too. You want to transport them that they want to be transported. So they want to be inserted or must into the story. And this is not hard in a business context, especially when you know what incentives. The difference the code and have how do you ensure that they find themselves inserted at different points of the story so it speaks to them. That is closely related to relevance, where obviously there's a close relationship between the story and the audience. And then for its influence. So, at the end of the day, it should have a certain level of influence on, you know, shifting a belief shifting the level of knowledge shifting a behavior. And that that is what would make an audience participate in a story and actually respond to it. Now, those are the similarities, whether you're in an organization, or you are there with your friends, when you're storytelling, those are for the four main things that lead people to participate in different stories. Now, those are the similarities. In a business context, audiences are also quite dissimilar in some ways one is, they could either be internal or external meaning, meaning one, one is, you always have to understand. It sounds quite obvious that you have to understand whether you are within a business to business framework, meaning that are you an agency, if you may, or a consultant or are you an internal analytics team, where your customer is actually people in the organization. Now, once you understand that dichotomy, then it means that you're able to answer a couple of questions that directly contributing to how you package your story. What is a stake, if you are within an organization, then the stakes are maybe slightly different to some extent to if you are a consultant or if you're a B2B organization. What is the culture? If you're within an analytics team within an organization, then you're part of that culture, and you understand how the organization works, you know how you do your things, you know how to communicate, you know who to talk to. Whereas if you're a consultant or you are an agency, working an agency, then you must be able to master yourself into a different culture compared to your culture. So I've been in scenarios where for instance I'm working in a tech company that is very casual, very high energy, very innovative, you know, move quickly and break things. That's sort of the ethos, but then you're working with a bank for instance where that is not their culture at all. So meaning that how you do things, how you package them, how you communicate, it's sort of still in a slightly conservative way, how you dress when you go into meetings, how you package your presentations for instance is very, very different. Then what's the historical context of actualization, especially if you're an agency or you're a consultant. What things have happened in the past that influence whatever story that this data is telling you or you want to tell me this piece of analysis of this data. What is a frequency that helps you determine as well things such as the tools that you will be using for your story telling. Are you going to use a deck where you just get a dashboard. Let's go how that dashboard looks like if it's top leadership, functional leadership, how does that look like, which brings me to the next part of that which is are they are your audience at the bulk of your audience strategic or operational. So, and here are a couple of questions that you should always ask yourself is, what are they using this data and these insights for. Are they using them to make organization wide decisions or are they using them to make operational interventions on different things that informs how you package your story. Are they organizational or is it functional so meaning that are you just talking to the commercial team or the upstream or the customer experience team or are you talking to someone who oversees the entire organization. Are they more concerned about the forest or the trees, they care about the big picture. And they want to be masked and for the story to measure around the big picture or they want the final details. Again, this is based on whether they're strategic or operational, how much time do they have. They're very, very clear on that whether you're making a presentation or building a dashboard, however, how much time do they have at their disposal, depending on the level they are, they are in the organization. And of course you have to ask yourself about the frequency and the tools for that you used to do that. The other question you have to ask yourself regarding the audience, as we aim to understand them is, are they technical or not technical, meaning that one, how much technical information is actually useful to them, especially for those who are building models for instance and even dashboards to some extent and different data analysis presentations. Do you care, do they really care about model parameters, features, or do they really care about what are you predicting or what are the business outputs and you know stop that. And they trust you already that you pay, you're a data analyst, data scientist, research analyst, and you know what you're doing just give me the results. What do they know already, do they have the context. So if you're talking to your peers for instance, and an example of this is, if you're talking to, if you're an agency or a consultant and you're presenting the data analysis presentation, so presenting this to your customers, your business customers, how much do they know already. Are they, are you talking to the head of a department that is very technical so the head of data on the other side or on the head of marketing, for instance, they have different skill sets and they have different things that they care about. So any work we've done previously, that informs for instance, or if you're talking to technical people, how much for lack of our citations or literature review you have to show them that this methodology has been used here and here and here, and this is why we chose it. And then breaking that down into this is how we implemented it. This is the method, this is the approach, or if they're not technical, then this is how you use this output. This is how you use this product, and that's how you use this dashboard. Without caring about all the work that went behind, you know, combining the different tables or whatever sort of computations did on the back end, if it was data that was collected from the field. That is something that you have to always consider. That's the first idea. So take a note of all, of that, of that, those different ways of breaking down the audience and why it is important, such an important input to how you tell your story. That's the first idea. The second idea is, once you've established that how do you reduce the cognitive load. Human beings, by and large again, they like stories because it's actually hard, easier to process the logic. And so you always want to play into that, make it easy for your audience to process whatever you're telling them or even not process at all, because the story is very well, well structured and plays into, into what is inherent to them. Now, stories are obviously more impactful and powerful than statistics, because, like I said, they take less effort of the brain to contextualize a lot of complex issues. Okay, now I know you're asking yourself, we are at Saturday, Saturday, and I've not talked about our at least from a technical point of view, and this is where it comes in. Obviously, this is a commended tidy approach of doing data science. So I'm not going to focus on everything else. We have the entire day to do that. I'll just focus on the last 10, which is, you know, communication. And I'm going to sort of go through a use case of how we can reduce complexity within one of the things I like doing a lot, which is sports analytics. Therefore, those who are either fans of rugby or have worked around much, then, you know, work with me, if not, then I'm just focused on the visualizations and not the data itself or the ideas. All right. So, when one of the things that we do when looking at the statistics for instance or whatever statistics you're looking at around sports. It's how much high intensity distance is covered by different positions within the team. And the underlying idea is the foundational concept to them. Different players have different skills, different levels of fitness, and they have different responsibilities on the pitch. So we have what you call your backs and your forwards. So if you throw that data of high intensity distance into a gg plot, then you don't, this is, you know, sort of what you get in the basics. So there are a couple of things that happen here, one is, and then I hope that if this was my life conference, maybe a physical conference and go around asking a few questions, but right now I'll just go ahead and share my thoughts. Sorry, Commander, I'm sorry to interrupt, but we are pressed for time, so we request you to be finalizing. Yes, finalizing. Okay, thanks. Thank you, Maggie. And so you notice that there's a lot of color. That's one color is distracting or brains. Obviously, not very good at attending to color, especially when it's a lot of colors. So one of the things that you know it's a we do is, okay, let's start moving a bit on the background for instance, and, you know, add some of the basics. What are we looking at? What's the title or the subtitle? What are we actually measuring here? And as opposed to looking at minimum group, what is a group? Now we're looking at position. Let's even go on step further and clean it back up even a bit more. Let's remove all the color, leave it at gray, and just leaving the outliers. We are able to see, okay, we're looking at the high intensity distance where the distance covered is where high intensity defined as the distance covered at more than 18 kilometers per hour. There doesn't seem to be, there seems to be a lot of homogeneity around the forwards, but there are three employers on the box, one is extremely good, the other one, and there are two who are not recovering a lot of high intensity distance. We can even go a step further and add some annotations to those outliers. So the first one is number 13, and that's how much distance they covered. The other one is number 11, and number 14, and that's how much distance they covered, which is significantly lower than number 13. Because the person you're talking to is the coach, or even the players themselves who are not very technical, then it's very easy for them to consume this and say that if our expectation for use number 1114 is to cover this much in high intensity distance because it has a correlation to winning or it has, it's a significant driver of us winning or losing matches, especially on offense, then, you know, you're not doing very well, right? I mean for other parts of the organization, if it's the management team, then this is what I need to see as well. And then let's keep it as various possible and, you know, avoid color as we tell the story because that's distracting. Only use color when you need to categorize something that needs to stand out because that's where the human eye will always go. The other idea is around, we always, we have a certain, I don't know, we have an edge every now and then to use tables to present information. And there's not much that you can infer from this, whether you're technical or not. If you may be technical, you know how to read tables at a little level, maybe if you're an accountant, you spend all that time looking at spreadsheets and you can sort of tease out some patterns from this. And so cognitively, this is a lot of load for anyone who's processing that. You could just, you know, for instance, do this and keep everything at gray and say, okay, what are we trying to show here? We're trying to sort of show the correlation for every single position between the heart rate of reliability and the high intensity distance covered. Ideally, those two should have a positive correlation. When people do a lot of high intensity distance, you do not want the heart rate of reliability is a key measure of performance, cardiovascular performance, to go down in any way. So, how about we do that, for instance, and I've spoken a lot about this idea in terms of how we use color, size, orientation, the shapes, the density, the hue. In terms of letting and making presentations and visualizations work for us in storytelling, but in the interest of time, I believe that. So, as you wind up a recap is one story telling always remember is an inherent human inclination make every single communication presentation, a story, optimize on not just the data but the insights and then at least those must always go hand in hand. You must always begin by understanding the context where the context is a combination of the audience and the expectations and the relevance and how you bring them into the story. You must always reduce your community, the constant load that you're putting on your audience by, by ensuring that you're cleaning up your visualizations as much as possible and using all these different techniques that optimize on the use of hue intensity, etc. A rule of thumb for me is only start gray and then build up from there. And then the last one is, that's all, the use of the use of pie charts as much as possible. Yeah. You can meet outside and debate but thank you very much. Thank you. Thank you for the insightful talk commander. So I'll allow you one minute to answer two questions and then close this. So, one question is, have you found yourself in a position where you need to educate your audience to get to the point where you can engage with them over your results. Any tips. Yes, any tips. One is if the audience is maybe fairly non technical. And then you can spend a bit of time educating them FAQs or perfectly send some periods especially before presentation, if that's what you want to do and tell them that this is what we'll be talking about during this meeting. And here is the background information or he is a preview of the presentation. I'm happy to answer any questions between on the meeting so that by the time we start in this discussion, we are all on the same page. Yeah, those are some of the things that are formed to work. If you eat a dashboard for instance that has a fairly detailed or potentially complex data set or or visualizations then make sure that you have notes that accompany that. And it is very clear that this is the idea we're trying to communicate. And this is how we arrived at that particular idea. Okay. Thank you for that. And the last question is what is one thing you do differently if you were given a chance to start the data science journey all over again. My mind has been a very boring route to get assigned because it was mostly academic and I've had the lack of going from school studying statistics and computational intelligence into industry and all those have all that has come together quite well. I'd say that the one thing I do do is sort of back maybe undergrad I'd have spent a bit more time programming, not just for now, but trying to do so. And, and, and that's something that I always tell to, you know, other students who come to me for advice and the people I mentor. Maybe you have a lot of time on your hands in school, try different things and develop your capacity to learn different tools, different techniques, and different ideas as much as possible from very early on. Okay. Thanks for that. So, so that's it. Just a confirmation Exco means executive committee right. Yes, it does. Okay, okay, okay, okay. So that's it. Thank you so much commander and next we encourage you to stretch for five minutes after which we will have our first two workshops, which have actually started and they're running in parallel. And this is our introduction to data management in our as well by Christopher Maronga as well as introduction to package development by Balugone Steven. So please refer to the email that was sent to us today for the respective zoom links. So enjoy the sessions. Thank you so much.