Creating and Fostering a Data Driven Culture with Looker's Head of Data Culture and Transformation

I hand it over to Zara. Keep in mind this is interactive. We did have to switch this one. That was a roundtable that was one of our most successful ones in signup. So congratulations. We switched it to a webinar. However, we still are encouraging chat Q and A. So I said chat. Excuse me, your Q and A. So shoot those questions over throughout the session. Zara will try to get to them at the end or throughout. So please don't be shy. We want you to join the conversation, like I said, with a comment or question. Again, if they don't get to all the Q and A today, it's something that we have and are able to send them. So these housekeeping items are a little different than usual. And just keep in mind that the session is recorded and it will be live streamed on our YouTube and then also available post event. So keep that on your radar. Anyways, without further ado, for our first session of SAASTR 2020, I'm going to kick it over to Zahra. Thank you for being with us.

Thank you. Thank you for having me. So yeah, I am the head of Data Culture and Transformation Programs for Looker at Google Cloud. I'm not going to give you my background because I don't want to waste your time. You're more than welcome to have a look online, but we have a ton of content. If you have kind of been to any of our conferences before, you'll know that this is kind of what I live and breathe. So I'm going to apologize in advance if I speak too quickly or bombard you with information, but I'm incredibly passionate about making sure people understand different buzzwords and things like that and how they can really grasp things like data culture and take them to an organization. So I really wanted to set the stage with you all first. So as with all buzzwords, culture has been mixed up with everything else and I feel like it's lost its meaning. It's really interesting when you speak to different people and you say, what does data culture mean to you? I don't think I've ever heard back something that I believe is data culture. So always open for discussion. But I want to set the stage how I think of data culture and data literacy. So I know not everyone did Latin at school, but sometimes it is easiest to go back to the root of a word that has been overused, misused. A company culture isn't defined by how quickly your company adopts a tool or how quickly it adopts a service. However, it will be an indicator of how a tool is adopted or how a process is adopted if there were no external forces at play. So we'll kind of go into that in a bit more detail later, but let's just do a quick exercise. Think of your previous company. So not, not your one currently, just to save any potential issues. But what was the office space like? So when you were going into the office, was it open plan, did you have offices? Or with more senior people in the offices, did junior staff get boxes to sit on and leadership got the kind of newest Herman Miller reclining chairs? What norms or values did the company have? So which of those were written in your handbooks, employee contracts, that sort of thing? And which weren't, but just sort of happened? So were those assumptions underpinned by those norms and values? So every company is different. The way that you kind of navigate what is a norm and what is a value is really when something goes wrong. So effectively, if someone is trying to think of good example here, if someone takes credit for someone else's work, is that kind of by the by or is that actually something that typically happens? If it's something that, you know, gets people's backs up when that normal value is violated, that's how you know that's one of those kind of symbols of that cultural organization. Bear in mind that obviously we're not working in offices at the moment, but you'll notice that some of that culture has kind of transcended from the office into your working from home. So again, what are those unspoken rules that everyone is just abiding by? And of course, which of those are specific to certain teams and countries? And hold on to that thought because these are things that we're going to talk about a little bit later in changing a culture of an organisation, because fundamentally we go to the next slide to help crystallize what we're really talking about. When we say a data culture, I encourage you to use the term data driven culture. What are the things that are symbolic? What are those norms and values of a data driven culture or a data driven organization? Is data held in high regard? Does everyone understand the value of data? What it brings to a conversation, what it brings to a decision? Does everyone have access to the right data, the data that they need? Is it hygienic? Is it accessible? And are business decisions made off the back of using data critically at all levels of the business, in every department? So again, not those sort of silos of your analyst teams, your BI teams, every individual is using data in some way or another. And at Various different levels. So those are just a few of the norms and values that a data driven business will exhibit. And so what about understanding the nuances of data? So if I could just said everyone's using data, but at different levels. We can't anticipate every single person in an organization to fully understand what correlation and causation is, or have examples of shark attacks going up at the same time as ice cream sales increasing. So if we define data literacy, and again bearing in mind what we just said, the definition of data culture is a quick Google search. You can use any Internet browser, you don't have to just use Google. It brought up 16 different definitions of data literacy just on that first page. But there were some common themes. And in short, data literacy is the ability to read, understand and communicate through the use of data. So for some, and likely a huge part of your organization, data is a new language and it can be incredibly daunting, particularly if there is this expectation that everyone has the same level of data literacy. But as with learning a new language, it's a process and it's often a slow one. And I think that's greatly misunderstood. Think of when you had to learn a language at school. Not just words, but there were tenses, clauses, nouns, structure. There was so much that kind of took you from, you know, that sort of low maturity phase to being able to converse and argue and challenge people in that language. The reason why I want to define both of these together is because we believe that data literacy is a real, really key component of data culture. And ultimately it's what helps drive the development of data culture within an organization. Data experiences are meant to make data the default option for everyone. You can use embedded solutions, integrations, different workflows, applications, dashboards. There are so many different things, but again, making sure that they make sense to the audience in which you're delivering them to. Seeing and using data every day is what can help enable everyone to build skills in the reading, understanding and communicating through the use of data. The more these two things can work together hand in hand, the more efficient your organization will be at moving towards a truly data driven organization. So when you learn a new language, you start with the basics. So we said certain words, phrases, and then you build up to reading, you build up to understanding, and then communicating challenging. And you want everyone in your business to be speaking the same language, but again, at varying levels. You have to start somewhere. I really recommend kind of doing a survey just to get an understanding of where people's data literacy is at. You Want to make sure that what you're, you know, you're not creating an anxiety there. This is purely, we want to know where you're at so that we can create the relevant enablement streams or training learnings. Whatever terminology you typically use in your organization, this is going to really help you build those relevant materials and those enablement plans for the different levels. And you know, by understanding that and presenting people with kind of information that makes sense to them is going to reduce that learning anxiety and make it easier for them to take on this new information. A really common assumption is that it's easier to focus on those who already work with data or have an above average literacy skill. Data literacy skill. The only problem with this approach is that you are widening the gap between analysts and end users. So therefore you're actually increasing the reliance on your analysts for day to day analytics. You're taking them away from doing the more complex strategic transformational analysis. If you can improve everyone in the business's data literacy score by 1 point, your mean data literacy will be higher than if you just invest in that small portion and that data savvy group. So again, it's that kind of shift towards a data driven organization and a data culture. Everyone knows the best way to learn a new language is to completely immerse yourself in that culture. So incorporating, like we've said, data into key workflows, using terminology as well to, I hate this term, but demystify data. A conversation that I remember having with an end user at a very large organization in the UK was commented on. They found the analytical the analyst team very daunting to speak to and had basically avoided all of these calendar invites from an analyst who just wanted to understand more about what they did. And it turns out just the term data was what was most daunting. So I sort of explained to him, well, you know, if you're choosing what to wear when you go outside, how do you know what the weather is? You can look out the window or you can, you know, get the information from the weather presenter. I don't know where you are, but in the UK typically there's not always 100% accurate, but that's another story. So I was able to say to him, well, you're taking information and you're making a decision. You're taking in the information on the weather, which is data, and you're making a decision based off of that. So what if every time you get a calendar invite from this person that has data in their title, you just change it to Information. And it was just a small kind of mental tweak that enabled that person to feel less daunted by the prospect of speaking to someone in the data team. But these are all real things that you have to be conscious of, cultivating an environment where using data is the easy option and the less scary option and not a hindrance. So remember, it has to be hygienic, actionable, it has to be fast. The as soon as you lose someone's trust in the data, it's incredibly difficult to get that back. So what we'll be talking about later on in the presentation is based on the assumption that that is all squeaky clean, already perfect. Ideal world. But inserting data into a workflow, what tools do they use every day? You know, Confluence, internal portals, embedded dashboard. So not only is the enablement kind of front and center, but they're taking in information without even realizing it. By bringing data to where the people are, you're already 10 steps ahead. So you really want to try and get to the bottom of what it is that they do. And pitched in a way that, you know, we're wanting to educate people. It's that whole thing about making sure that when someone does leave the organization they have gathered, you know, you've provided them with a stepping stone in which to do that. Everyone is looking for someone that is data literate now, so you are helping them progress in their career. So like we said, don't kick start that anxiety. You're wanting to really take people up a level depending on where they are in the organization. So having those curated pathways and the enablement coupled with any technology that you use. So remember, leverage the technology to help with becoming a more data literate, data driven organization, not the other way round. But first and foremost the cultural change, that's the part that's really hard. You can't just unleash a data tool or a data literacy program and hope for the best. There's so much to consider. So along with that, when we're wanting to take them on a journey and meet them on the path that they're already on, how do we know where to meet them? How do we know what a data experience would look like for them? And of course, how do we do that at scale? Like I've said, the assumption here, your data is in good shape, it doesn't matter what tool you use, underlying data is spic and span, finely tuned warehouse. And with that all done, we know that we're not going to risk losing trust when we start onboarding Users, things like that. Crossing that chasm from being tactical with your data to transformational is a massive, massive leap. It doesn't take a few months and it probably will take you more than a year. So bear that in mind, set expectations. But it's only achievable if every part of the organization is wanting to use data effectively and understands the importance of data. Again, I'm going to come back to that later, but having that kind of clear vision of where your organization needs to go, how it needs to keep up, how it needs to make transformational decisions at every level, and not just at the leadership level. Companies always have such great intentions when they embark on this kind of data driven culture, data literacy program, that sort of thing. But more often than not it is very much about kind of giving someone a login to a BI tool and kind of boom, we're done. We're a data literate organization. It's just never worked. I've never seen it work and if someone can tell me it does, then I would love to learn from that company. But what I'll touch on is methodologies for a product model and some tactics that you can utilize. We'll do a bit of change management stuff as well, just to help ensure that that transition from that tactical to transformational. I've just lost my words. Tactical to transformational is just as smooth as possible. I could say that maturity of your data stack and data and how you use data in your organization. I realize this sounds backwards, but you want to start at the end. So however tempting, don't build everything to the nth degree, don't build what they already have in one tool or if you're going through a tool change, anything like that and then just unleash it. You want to start with your end users, just like a product manager does. And it truly starts with understanding requirements and engaging with end users. So you may have seen this before, and we do talk about it a great deal at Looker, but it does tend to be the model that we see being most effective. Data is always going to be a company's most lucrative asset, but like a ton of things in raw form, it's just indigestible to the majority of an organization, particularly one that doesn't have that high mean of data literacy. So Looker's own chief data advocate, Daniel Mintz, he speaks a lot for us. He speaks on this topic a ton and this is a really good blog post about it's time to hire a data product manager. And he talks about that traditional BI department where analysts are trained to act as a service organization. A request for a report comes in, it joins the queue. What's delivered is exactly what was requested. And again, going back when we were saying about what happens is analysts tend to, when that gap is widened between those with a low data literacy and those with a higher data literacy, that dependence becomes so much greater. And unfortunately, you're then hindering the analysts in making those transformational predictive insights rather than always looking historically. Like I say, the service model, it works for some people, but at scale. And really, if you're wanting to create this data driven organization, you need to have everyone on the same page. Businesses that want to drive those database decisions and not just within one team. They have to use these standard change management techniques and this product model, this product mindset to really make sure that something that what is being built is exactly what they need and not what you think they need. So product managers often get those specific requests, like we said. But unlike in a service model, they consider a few things. So who is making the ask? What are their needs? Why do they need it? What's the goal behind the ask? And who else needs to be considered when the solution is designed? I always encourage customers to really understand what the goal behind the ask is because that's where an analyst is worth its weight in gold or his or her weight in gold. They should be able to translate what that requirement is, the action that the individual is trying to drive. And actually they should be able to recommend whether that is the best way of doing it, if there's another way of doing it, if it's a vanity metric. That guidance that consultation is is what also increases data literacy. Just that engagement. And it's far stronger than any training program that you just kind of kick out and hope it sticks. So asking those types of questions allows them to take a strategic approach. And you can design a data product with those clearly stated goals and business outcomes. And each user to an extent has a fit for purpose product, a really good way. User stories, wireframe testing, all of that will be indispensable and it will all be things that you'll want to leverage again in that change management process. So many benefits from kind of taking this approach. It gives you innovative solutions, innovative solutions. You're not just kind of lifting and shifting from one tool to another. You are understanding what the business problem is. You are then very easily able to report on whether something is working or not. And it helps to design and deliver a thoughtful solution. Again, you have to be conscious of the people coming to this very shortly, they are human beings. And keeping their needs in mind means that you will provide a data solution that not only you see the value in, but all of your users will also see the value in. And like I said, a product is well designed. It will actually help encourage that data literacy along with creating a data literate organization, you're then creating that data driven culture where people are relying on data and going to data to have those kind of conversations around what needs to happen next. Change management is for me fascinating. And the reason why I talk about it so much is because fundamentally what we're talking about, building a product that everyone can use or changing the culture of a business to be, you know, move from being transparent, whatever it is, to a data driven culture. It is organizational change, however you cut it. If you're wanting a data driven organization, you are changing everyone from their current state to the desired state. Why change management is so important? It's about the people side of change. It's not the process, it's not the tool, it's not the enablement program. Although you should rely on your tools to make that change as easy as possible. The people you're changing are human. And it's so easy to forget that, particularly at scale. I've worked with companies where they've had tens of thousands of users and one individual in sales or marketing is very far away from their thought process, understandably. But there are ways to do it at scale as well. Bearing in mind all the time workers in their life, they have different learning styles, they have different experiences, different backgrounds, anxieties and, and you have to be conscious of this and give them the time and space to change. And that's why earlier you might remember I said it won't happen overnight, it'll probably take longer than a year. And actually we're talking about a couple of things that you're looking to change here. So up leveling a particular skill, knowledge, but also a culture which if we kind of revert back to the beginning in that exercise, what if one day, so picturing your old office, you went in and where, you know, it was all open plan, you'd gone back in on the Monday and everything was closed off and everyone was in pods, how would that make you feel? There was no explanation, it just happened. What would probably happen is everyone as an individual would embark on this change curve, very similar to the stages of grief. But we're going to put a positive spin on that. And initially, you know, guys can't, this can't be happening to me. Where is my box? Or if you're in leadership, where's my Herman Miller chair? Shock, denial, frustrate. All of those things, you go through this curve, but we know that that happens and we know that people oscillate from one phase to the next. But there are also so many things you can do to make that journey easier, to reduce that friction. And particularly when we're talking about something like data literacy as a skill, something that can only be a positive thing really for everyone and shifting towards a data driven organization. Again, there's not a ton of negative there in the messaging. It's just what happens through that change in the individuals that can create friction. If, of course, you've done your homework, you've used that product model, you are able to tailor some of the messaging, you're able to make sure that what they're being given is this end product or that goal, that you're trying to shift them to that current state, to future state. It's for the good, it's for the good of them, it's for the good of the company. You're wanting to drive everything forward. There is still a lot to be scared of though. And you know, you've got to validate that and understand that. But equally, you can't do that all by yourself. So again, how can we do this at scale in the interest of time? I've just kind of chosen four things that I do tend to see as probably the most obvious but also the most overlooked processes and planning phases that I see. Particularly when we have customers that had been with previous tools before and they're moving the whole organization from one tool to another. Super, super easy to dive straight into that technology. And that's kind of for the people that you know, probably on this webinar now, that's the most exciting stuff. Building what you think someone needs and then hoping they'll use it again. It's such an easy trap to fall into delivery, wanting to deliver something, the good intention is there, but it's not going to stick. Needless to say, there's a huge amount of technical debt that comes with that method due to the changes that you inevitably have to make once users are logging in and haven't returned or start really kind of hammering home like this is what I actually need versus what you've kind of given me today. So it's arguably far more straightforward to change the way a system functions than it is to change a human's way of working even harder to change a group of humans, particularly in a community. So if our goal is to make data the easiest option for everybody when making business decisions, then we need to be very clear on what is valuable to the customer and how we can serve that. So like I say, in the interest of time, we're just going to scratch the surface on these. But I really want to be able to give you a springboard for each of these things that you can go away, you can research and apply the parts that make sense to you. So I strongly encourage you to put time into creating some of these plans around these work streams. And what you'll find is that each work stream should inform the other by providing more context, understanding and also helping you empathize with users and their requirements. So remember, they're not stakes in the ground. They will evolve, they'll take on different shapes as the journey goes on. And I'd actually be concerned if they didn't. But it's good to have a template. It's so good to have a record of what's worked and what hasn't worked. And they're not static. Like I said, they will evolve. But having these cornerstones just fleshed out prior to even launching a product or starting a new program, your data literacy program, it ensures that your initiative has a considered start. It has realistic timelines and clear outcomes. So we're going to talk about vision again. I know we're jumping around a lot, but clarity and change is arguably the most important thing to encourage feelings of security. So there shouldn't be any underlying message. It should be understood by everyone. And I always tell clients that it also kind of ensures that they are held accountable. So trust is a really huge part in the emotional process of change. And again, I don't expect any one person or any one team to be able to do this. Lean on stakeholders, lean on change agents to shape that vision statement prior to kind of launching it or unleashing it. And a surprisingly overlooked requirement provision statement is that it's understood at all levels. It has to be something that people can repeat. So work with your stakeholders, work with your change agents and try it out before you kind of say release it to the wild. And also it can be iterated. But just be very transparent as to why you're iterating it. This didn't work. Didn't work because of this. This is why it's now, this communication is massive. So stakeholders in your large scale rollouts, stakeholders are indispensable. I know I'm going to keep saying this about everything, but Strong relationships are required and this is more commonly than not misunderstood because it doesn't have to be through one individual, it doesn't have to be through one team. Again, it's, you know, there is some strategy behind it. But before the rollout you want to have, or before whatever change that you're making across an organization, understanding what those relationships are, who they are, is going to help you kind of ensure that the messaging is correct. It's going at the right time. These are people that are more able to have a message received than if it's coming from just one person. So it's all about who they are, if they're respected or how they're respected, and also what influence they have. There's a number of different exercises you can do to choose your stakeholders as well. What's also great about them is they will have had experiences with change in the organization. So understand that experience, make sure it's baked into any messaging that you're sending out. Listen to their teams, their concerns to build that trust, because you'll want to leverage that information for your communication and training strategies. But equally, you want to make sure that you're kind of cognizant of the fact that these stakeholders are also on a journey of change. Whilst, albeit that they'll be on that kind of change curve ahead of everyone else, it's still a change for them as well. A really good way, or at least I find it helpful, is just having names on a radar. So at any one time you have a good idea of who your stakeholders are. And I recommend supplementing this with a spreadsheet of names, dates in which they are engaged, their power, influence and also along with their interest in the change. Were they for it, were they against it, they kind of about it and it will evolve. So people will move into different parts of the radar, they might drop off altogether and others will appear. So it's also a really good kind of roadmap for your stakeholders to let them know, we'll need your help for this, for this quarter, but then afterwards we'll be working with different stakeholders. Change agents, another one that is so overlooked. There will be nuances to any change, any project that you're rolling out that you didn't anticipate, and there'll be challenges that you just never expected. Nine times out of ten, you'll find out about these from a change agent. So that's someone on the ground, in the weeds. Typically, we'll message that back to a stakeholder, depending on how large the organisation is. But I also encourage change agents to own a part of any training piece for their arena. They are typically a really good individual to use to help translate anything around the change, anything around terminology. They know the methods that work for their departments, their teams. And also having having someone in the team roll something out, the buy in is far greater than if it's, you know, some external team coming in. Of course, when they're building that training, lean on the internal training teams who are typically always happy to help as well. But in large scale deployments, a change agent network is hugely beneficial. So again, can't emphasize enough how important this is. Having at least one person on the ground per department that is breaking down those silos, communicating to the team in a language that they understand, also testing any pre release solutions that's going to provide you with another level of feedback that you can bake into that change process. You can update in your plans, you can tweak tools, training, you know, communication plans and gossip is typically what comes up through your change agents as well. So it gives you a good idea of any issues that you need to mitigate. Could be that it actually inspires a change in the communication plan. So massively oversimplifying again, but in my experience, the communication piece is again incredibly overlooked and misunderstood. I think having a rough outline of your communication plan that will provide you with an anchor for your messaging. It's so easy to just say, oh no, it's fine, we'll just smash out an email here, or we'll put it in the weekly all hands email that goes through that everybody reads from top to bottom. But having a rough outline of what the messaging is, if at any point things get overwhelming, it's such a relief to have something to go back to or to have a template that you can use for a particular situation rather than having to do it on the fly. Again, a simple spreadsheet works really well. It will suffice, like just having the owner of the content, so the person that created it, the sender. So again, who is the sender? Are they a stakeholder? Are they a change agent? Linking back to your kind of stakeholder radar the recipients, the desired outcomes and the medium. I always recommend to have the medium on a communication plan because you'll realize the ease of leaning on one form of communication over another. Having that visual of how much you're depending on a certain mechanism is helpful. And you'll probably realize how much you're depending on email, which is a great way to share information, but it's a terrible Way to encourage open feedback. There are really good kind of basic communication strategies that you can use. Again, I'm very much of find what works for you change management. I think from my perspective, a lot of it is just common knowledge and it's finding theories, practices that work, but always being able to adapt. And it's the same with the way that you communicate and your communication plans. Again, it's just always maintaining that people first approach. So again, leveraging the information from having that product model mentality, all of the information that you've garnished from your change agents and stakeholders, baking that into your messages from the ground and developing your communications to reduce the anxieties that are likely to build over time. A lot of the communication at the beginning of these changes as well is actually internally to your change agents and your stakeholders. You know, what's required of them, what's the network, what's the community that they're going to be a part of. It's also a really good way of having that preliminary communication plan, seeing what worked, what didn't. And again, this will be severely, severely sounds dramatic, but the communication plan should really be done with the current organisational culture in mind and also that future state as well. It's little nuances. Again, if you do have a communications team, I strongly recommend leaning on them. You know, it's what they're trained to do. Anyone in marketing also has a really like, knows far more than I ever do about messaging. But what you're wanting to do is get people excited and again, having this plan in place, having an idea of what you're wanting to communicate at certain times, you'll be very grateful for that. When you've got, you know, a whole department which can be a few hundred people and sometimes a few thousand people, and they're all in that denial phase of the change curve. And you've already got a template for communication to reinspire and motivate them and kind of try and get them moving through to the next phase. So as always, I believe tons of benefit here and I know it sounds backwards kind of there's a ton to plan, particularly spitting out data culture and data literacy. The two of them do work hand in hand and I genuinely think that you need both of them to be able to really kind of, in two years time say that you are a data driven culture or you have a data culture. So spending time on putting what we've spoken about into practice before you kind of roll out these changes or run out any messages about everyone in the org Becoming more data literate or that being the goal, it means you can be more deliberate as well. So with your resources, nothing more efficient. And you're addressing and to an extent mitigating that people side of change, which is also about change management. And that can be the difference between you achieving that kind of coveted data driven culture failing. And that's irrelevant of kind of what tools you have, what your tech stack is. So like I say, people are what will kind of make you data driven as an organization, but they're also the people that can stop that from happening. So I have kind of raced through that a ton of different concepts, but hopefully you can kind of digest some of that. And like I say, my intention here was to really give you a springboard of things that you can go off and research, figure out what works for you, what models work for you, and if it's not you, again, that's absolutely fine. But there will be people in your organization that do want to do that and those are the people that you'll want to leverage. So with that, I don't know if we've had any questions.

We do have three questions, Zara, so.

I don't know if you are able.

To pop in there and see otherwise. I can read them for you.

I can see them. Okay, so the first one, how can you help make a change if you aren't a decision maker in your company? So this is a really interesting question. You don't have to be a decision maker to make a change happen. I realise that's a really easy thing to say. There's actually a ton of really good articles on how to kind of manage and move projects along when they're not your direct report or things like that. But fundamentally it's depending on where you sit in the business and what your role is. If you can get buy in from leadership. Again, I know that's easier said than done, but I mean there are examples where, you know, we've had individuals wanting to roll out this change, but actually fundamentally leadership haven't understood the importance of a data driven organization or they've not understood the nuances. So being able to give them that data, give them something that they haven't had before, making sure that it's something that they can consume. So I don't know what their data literacy level is and continually giving them those reports, giving them that feedback, also connecting leaders with other people in different companies that they respect who have already started that kind of process of change. Again, if you can't get people in that Kind of leadership team getting kind of buy in from other managers and other stakeholders that may have those relationships is also a really good way of doing it. But fundamentally, decisions happen and change happens. When there is a desire for change to happen, there are tons of levers that you can pull and again, you have to be strategic around who pulls those levers. But you know, any MD or CEO, if the business isn't doing as well as it can do, and you've got competitors that are making kind of, you know, these transformational changes off the back of using data, then you know, that should be motive enough to at least try kind of embarking on that change. Okay, so next question. How long does it typically take to roll out a data driven culture? I hate to be that person that says this, but it is kind of how long is a piece of string? I haven't seen it done in less than a year, two years. And I think it's all well and good making decisions based off of data. And that's kind of, I know what I've just been hammering through, but actually what's also really important is that literacy level and the understanding of how to think about data critically. And of course, if you're always hiring, there's always enablement, but making sure that there's norms and values that are kind of synonymous with the data driven culture, making sure that they're embedded in so many different levels. So all of your kind of job descriptions when you're hiring, things like that, that's the way to kind of get the ball rolling and to ensure that you have got kind of an organization wide culture. But fundamentally, I would say it doesn't matter how many people have tried to do some massive org wide change right at the top. There is so much strategy that has to go into it and you could even have a 20 person company where you could argue that one person doesn't use data at all, doesn't think that there's any value in it, prefers to kind of lick their finger and stick it up to work out what the wind direction is. So I can't give you a canned answer, but I think again, having all of those plans in place, it's really good to be able to look back and in hindsight see how far you've come. So again, doing the data literacy survey at the beginning, kind of doing those user interviews, user stories, how long does it take you to date do all of those things? So you've got always got metrics that you can track. Okay, another question, what advice do you have for someone stuck in the frustration, depression state of the process. Okay, so again, another really interesting question. The one thing I want to make clear here is that people can oscillate. So it may be that you have to have a variety of different things to kind of target that kind of that phase. And they'll kind of roll out, they'll go into the experimental phase where they'll start, you know, practicing with data or building visualizations, whatever it is, and then they'll kind of roll back into it. So you've got to keep a measure of that. But in my experience, I have found that community is the biggest thing so doing. And again, it depends how data literate that group of people is. But engaging with someone I've done actually obviously pre Covid recommending that someone take someone else out. And it was actually a very big team, but only one person seemed to really be struggling in an automotive company I was working with and taking them out of the office, having a coffee and actually not talking about the kind of change that they were going through to be more data driven. And what it did was it just created a connection. And also what they did was they recommended someone that they should speak to. In another team that had been through that phase already, this was someone that kept kind of falling back into it. They felt like they couldn't learn, you know, the tool or wasn't what they signed up for. So connecting them with someone else that almost ended up being a champion, giving them those kind of community events. So hackathons are really good. Again, do it based on the level of understanding, the level of literacy, but, you know, giving people fun information to find. There are so many fun data sets out there, so it's kind of taking them out of the situation they're in, but letting them leverage those skills in another way. There are so many different things. I always used to take donuts, and that's so cliche, but that always used to help a ton at kind of events and things like that and partnering them with other people. So partnering them with on a project, highlighting any of the good work that they've done and effectively just breaking things down in more manageable chunks. Okay, another question. What are the biggest data related challenges you're tackling at the moment and how are you solving them? I don't know how much I can.

Say.

Ironically, I would say internally it's, you know, there's so much data and it's how do we, how do we use all of that data to build programs? So it's how am I solving them mostly at the moment. I mean, if you could see my desk, lots and lots of plans, lots and lots of whiteboarding. And I always start with the outcome that I want to drive. Probably a very simplistic view, but I mean, I can't show you what's on my desk, but the outcome of what I want to drive. So where do I want to get to? What do I want to use the data for in this example? Actually, what data is missing? What data is missing that isn't giving us the full picture? What data do we have that actually is probably not quite right or it's not telling us what we really need? And that's part of that data literacy thing. So one of the other ways that I'm trying to deal with that at the moment is coming up with some internal data literacy programs just to kind of get us all up to the same level, but also kind of, again, leveraging stakeholders and kind of communicating with leadership around where we're at, where we need to get to what the problems are and being very clear about what buy in I need, what communication messaging I need.

Awesome. Zara. I actually have to, unfortunately.

Okay.

You've done a great job and we've been so lucky to have you. And what I'll do is I'll make sure I know there's a few other questions in here and I'll make sure you guys get them. So if you want to follow up or do it in a tweet or what have you, you guys can. Thank you so much for coming and thanks for helping us kick off Sasterscale.

Thank you. And I'm looking forward to dialing into more of the sessions as well. So thank you for having me. I've really enjoyed it.

Awesome. Thank you. For the rest of you, please keep joining us on the rest of the roundtables today and then tomorrow we will see you later today. Have a good one. Thanks, guys.