why dashboards die—and how to save them with Allison Horst

TRANSCRIPT

 Welcome to the Storytelling with Data Podcast, where listeners around the world learn to be better storytellers and presenters. We'll cover a wide range of topics that will help you effectively show and tell your data stories. So get ready to separate yourself from the mess of 3D exploding pie charts and deliver knockout presentations. And with that, here's Simon.

Hi everyone, and welcome to the podcast. Now the topic of today's conversation brings back a lot of memories for me. Before joining the storytelling with data team, I spent many years in financial services working in banking, and much of it within the data and analytics team within that particular company.

Now, at the time, it was a relatively new function. We were all finding our feet. We were starting out with lots of manual reporting using quite a bit of Excel. Before, gradually developing some infrastructure, some engineering, a bit of a performance platform, if you like. But the process was mostly reactive.

We'd receive a request from the business, and then we'd just go off and build it. So there was always this disconnect between the business and us, and we were producing some pretty solid KPIs and metrics, but there wasn't any real sense of engagement between us. Now things came to a head when we rebuilt the core reporting platform using a more modern, scalable technology, a plus from our point of view.

And so, certainly from our perspective, it was a real step forward, but the business unfortunately saw it as a step back. They suddenly lost access to some of the metrics they were used to. Even if those metrics were on a slower and less sophisticated system, the feedback was negative, and morale within the team certainly wasn't at a great point.

But that's when we turned a corner; we decided to completely rethink our framework, and the biggest change was securing some executive sponsorship. So we had two senior leaders within the business who became fully involved in the project. They didn't just sign off; they attended the weekly huddles, joined in with sprint sessions, and played an active role in the development.

And this changed everything. We could sense check ideas with them, validate whether what we were building matched the business needs, and crucially, they became advocates for the system. So when there was noise from the business, where's this metric? Or why isn't this feature ready? They defended us and stood up for our work.

So this was the first time that we felt truly part of a collaborative environment, and it made me realize just how essential this conversation is when working with data, and today gives me great pleasure to be joined by Allison Horst, who shares the same passion as I do in ensuring there's this real, true collaborative pathway between those producing data, whether it be building dashboards or presenting insights to the business.

So welcome, Allison, to the storytelling with data podcast.

Hi, Simon. Happy to be here.

Great stuff, and although we've never actually met, we did have the chance to meet in a pre-podcast chat a few weeks ago. I thoroughly enjoyed that conversation and how it flowed. So it's pretty clear to me that you have a huge amount of enthusiasm in this space.

So before we get onto that, and the main topic of today's conversation, it'll be great to hear just a little bit about yourself. What was your pathway into where we are today?

What feels like many years ago now, I studied environmental science in college. I did my PhD in nano toxicology, and part of that was trying to figure out ways to visualize kind of complex environmental data. At the time I was using. A lot of standard tools that people still use to do amazing things in data analysis, like Excel.

And then, when I needed to bulk up on the reproducibility, when I needed to automate some of my work, I started learning how to code, and I started writing code in R, which still is very dear to my heart. And while I was doing that, I also started teaching at the university, which led to over a decade of teaching in data analysis, data science, data visualization, and science communication at UC, Santa Barbara. And as part of that educational work, I also started doing illustrations because I just wanted an engaging and welcoming visual way for people to learn material and get excited about material.

So a lot of the work that I did was also actually artwork for data science education. This led to artists in residencies with the National Center for Ecological Analysis and Synthesis, and for our studio. So after doing a lot of artwork in data science and a lot of education and data science, I made the move to Observable, where I am now working on the developer relations team to help folks build more used and valued data products for their teams. Work with tools that help people to collaborate more meaningfully and frequently on projects so that they don't get into some of the positions that you were describing at the start of the podcast, where you feel like you're reacting to things, and then that can lead to some negative feelings.

So yeah, now I'm at Observable. Really excited to be here to chat with you today about collaboration and making sure people are staying in the loop from the beginning so that you can produce more, more meaningful, used, and not rotten dashboards and data products.

Good stuff, one thing that really stood out for me there, Allison, was your love for R as a coding platform. That brings me back to the time when I first started, I used SAS. I don't know if even SAS is regularly used. I think it is still a widespread product, but certainly it's one of those languages that you have to learn pretty much by heart, by par, if you like, because there's no other way, it's not so intuitive to learn.

And I always remember some of the syntax even now, and this is 15, 20 years ago. So that first coding language always sticks with you, isn't it?

Absolutely.

So complex data science. I guess in terms of the environmental space, so what we were talking about 13, 14 years ago or so, was the environment such a hot topic back then? I guess it is really built up over the last few years, but maybe it wasn't quite so much in the headlines as it is nowadays. How did that play through?

Yeah, I think it goes through waves based on, like, changing maybe political perspectives and what's going on in the world. I think it, even back then, even when I was studying environmental science for my PhD. There was a lot of emphasis, a lot of funding being put into environmental research.

And people continued to do really exciting and important environmental work like they do today. I think there's just these waves of support and interest and emphasis on sharing environmental work. But certainly even back then, even, far before I started, there were people, 30, 40 years ago, doing really incredible work on climate science and investigating climate change.

That's really inspired me and led a lot of the data work that I've continued to do. Even at Observable. I get really excited to work with environmental teams who are trying to find better ways to visualize data. Especially since environmental data can be huge spatial data that's coming in really quickly from remote sensing or other sources.

So it's really exciting to find ways to simplify that and make it digestible even when it's these massive data sources. And then we'll certainly be talking about how we make huge amounts of data more concise, and how we bring that to life, because I think that's a huge topic and one that probably resonates with a number of people listening, because everyone now don't they have had access to huge amounts of data, flooding in at all times. Real-time information, real-time updates coming through. But how do we get it to that level where it's actually now meaningful for an audience? That's a great topic we'll come back to as we progress. One thing I do wanna point out is that Alison mentioned some artwork on her website.

Certainly, I'd encourage you to check that out. That's a lot of fun to look through. But as I was listening there, Alison, to your history, where would you say the biggest impact or learning has come to you in regards to just having this sense of collaboration, how important collaboration is between those producing information, that the dashboards, the reports, and those who maybe have requested it, the stakeholders, the business.

I really started seeing how critical this was when I was advising graduate students on their thesis projects, when I was teaching at UCSB. The process of advising a lot of these data science students’ capstone projects, which students were doing in collaboration with companies and organizations that had submitted proposals, was seeing that students would very quickly, once they were matched to an organization or company, for this capstone.

Once they got their hands on the data, the first thing that they wanted to do was start building, which totally makes sense because it's really exciting when you get your hands on some fresh data and you like have some goals from the client is just to start building something and it's really hard to try to share with them the importance of like.

Maybe slow down a little bit because that's gonna keep you from doing a bunch of redundant work in the future or doing a bunch of work that gets unused. As an educator, that's a balancing act because you don't want to diminish their enthusiasm for things like writing code and just like trying to create their own app.

Curiosity and ambition are really awesome. And at the same time, it's important to help them learn the importance, especially once they get into a career. Being very thoughtful and careful about their time and other people's time, and how you get from A to Z, from ideation to an end product, so that you're not getting to an end point.

And then sharing it with a dashboard or a visualization with a client, only to find, way too late in the process, that what you've created is not easily understandable by them, or incredibly useful to them, or that they actually wanted something very different from what you've created. I think that process of repeatedly seeing learners dive into building without maybe the careful questions and ongoing collaboration along the way, and then seeing the pains of that.

Late in the process, learning that they're gonna have to do a lot of building at that point. Really reemphasized and made me excited about helping people to learn better ways of collaborating in their data work.

That brings back, again, a few memories for me, and I'll put my hand up to being one of those people who did have that temptation to, especially when I was a bit younger, very enthusiastic, of course, wanted to impress. And to produce something. And I guess with the tools that we have nowadays, it's probably a little bit easier than maybe it was in the more distant past, too.

To create things. For example, we use Tableau, and so you just download your data, put it into the Tableau, and then you can just drag and drop and a minute. You just create all this myriad of different views very instantly, very quickly. And of course, before you know it, you've got so much there and you feel like you wanna show it all, and that's when it becomes overwhelming.

So yeah, taking a step back. And really thinking about, what is it you're looking to share, and what is it your audience really wants to see? And there's one thing that we typically encourage in the team here is storyboarding. Because I think it's a really nice way, a nice low-tech way of just getting a sense of what your content might look like before you then commit to your tools and start building things.

Just plan things out. It helps you get away from your desk as well. I mean, that's a nice thing to be able to do. Just grab some Post-it notes, maybe, and just start to craft out some ideas that you might have, brainstorm different options you might have, and the point that you mentioned there, around, someone producing all of this information, sharing it with their audience, and then getting the feedback that's not really gonna quite work.

Well, that's all avoided if you do spend a bit of time storyboarding because you get that sense immediately of whether this thing's gonna work or not, and you can just remove that sticky note from the pile. There's no sense of loss there in the same way that it would be if you were to present that information to the business.

So yeah, huge amounts there that certainly resonate with me in my personal journey. But also what we typically see as well, where, again, it's just a tendency, for those working with data or have a passion working with data, want to just provide information, provide their work, show their work back to their audience without really critically thinking about who their audience is.

Yeah, it's a really great point. I remember a couple of words you mentioned a while ago, Alison, actually, that I really thought were quite interesting in terms of dashboards and trying to make sure that dashboards are used and feel valued. And it sounds, I guess, in some ways, a little bit obvious, doesn't it?

Of course, dashboards are gonna be used, aren't they? Are they?

Oh, I wish that the answer was yes, but so often I find it heartbreaking that analysts who have put in incredible amounts of work into a dashboard or a report that they imagine will be sustained and have a long-term impact. And people will go back to it every day to help them with their own decisions and in their own work.

And then what they find is maybe some initial interest in engagement, and then that quickly dies off until a dashboard isn't being used or something is broken, and it's hard to fix. Or new data comes in, or a new question comes in, and the energy around the dashboard is lost, and so it doesn't get added.

So I think there are a lot of reasons why even dashboards that are maybe initially successful end up in a crowded dashboard graveyard that companies have. Which is really unfortunate because there is value in those, but keeping people engaged with them long-term, making sure that they're being kept up.

That can be an entire project, all on its own, upkeep, but usually, time isn't allocated just for like dashboard upkeep. It's like, as soon as a dashboard is completed, there are six other requests in the inbox that are taking priority. So I think that finding lightweight ways to make sure that dashboards are staying relevant, make sure they're staying front of mind for people, reminding folks like, Hey, here's a specific thing that I think might be interesting for you, so that they're reminded to keep coming back.

The really important parts of dashboard development aren’t just making the thing because a dashboard is not finished, like a successful dashboard isn't ever done. A successful dashboard is a starting point that brings value to the team, but should then evolve to stay relevant, making sure it's always staying up to date, making sure things aren't broken, so that it becomes this long-term place that's a hub for people to have discussions and make decisions.

Yeah, that sense of evolving is a really important one because a lot of times I feel like there's a feeling that once the dashboard is built, once the team, the engineering team, is given the data, the analytical team has created the dashboard. And served it off. And the final team has made it all automated and all of that good stuff.

I think there's a sense of done and completed. And of course, to your point, it isn't really ever done. We should always be looking to make sure that the dashboards are meaningful, they're still engaging, they're still presenting the right metrics, because businesses change their priorities as well.

And I think that's often the case of why these things can go a little bit stale, isn't it? Because they don't need to see this information anymore. We wanted to see it for a few months, but now it's done. We can tick that box off. I always remember one particular dashboard that we created that I used to take in and present to a leadership team.

And it was a weekly session, and once this dashboard was created, it was fantastic, like fanfare when this thing came in, everyone loved it, and we had a great discussion. Took away lots of actions, lots of thoughts. Brilliant. Next week, pretty good as well, but slightly fewer actions.

The week after that, slightly less, and you can imagine where this is going. By the end of a couple of months, really nothing was happening. Everyone had seen these metrics, everyone had seen the movement of them, the trends of them. Really, there wasn't anything to discuss, and I began to dread going in to present this information, thinking I've got literally nothing to say about this dashboard.

So in instead of doing that, I began to turn things around and say, okay, well, within this dashboard, is there just one KPI that we perhaps we wanna shine a light on and do a bit more of a deep dive on? Because, of course, dashboards are relatively high-level. You can always go further into the data.

And I think once I began to do that, things changed. So it was more of a conversation of, well, the dashboard's there, but we've seen one thing that we wanna just highlight today for you, a focus point if you like. And then bringing that to life, just really. Changed the conversation. It made every one of those weekly sessions a lot more fun because it was different each time.

The audience, the business didn't know quite what we were gonna be sharing perhaps, so they were always interested and invested in it as well. So I think that's one way of turning around that, a dashboard. But the other way that I think as well, from a more low-stakes perspective, is just for those people who are building it and creating it.

Just take a moment to look at it because so many people build it and send it or refresh it, and actually don't spend any time reviewing it. Just take a look, and then even if you're just sending out a quick note to the audience of this dashboard, just to say, the dashboard's been refreshed. A couple of points that I saw might be of interest to you.

It just gets people thinking in that slightly different way, and there's that balance between an analyst having good technical skills and having really good ones. Business skills, if you like, softer skills, understanding the business, and that bridging that gap between the two is hugely important, and that's just one very small step in terms of being able to do that.

Have you seen any others that may have come across?

I totally agree with that. I think that's an uncelebrated and maybe undervalued or underseen part of a dashboard developer's job, which maybe they don't realize, is also their job is being a hype man for their work. Is like the realization that if people aren't looking at a dashboard that you've created as frequently or as long-term as you had hoped, it doesn't necessarily mean it's because it isn't valued or couldn't have value. People are busy; your dashboard is not the one thing that they have bookmarked. They have their own tasks. They're looking at other dashboards and reports. And so I think it's incredibly useful when our VP of marketing will occasionally, even if it's once a month or once a quarter, come back to the team and say, Hey, we haven't taken a look at this in a while.

There are some interesting things here; let's check it out together. And I have this feeling of Oh, right, thank you. I appreciate this reminder because this is really valuable, and my time has just gotten bowled over by all of these other projects. So I think having the mindset that not just building the thing, but also being the person who can reconnect your team and stakeholders to the dashboard and send reminders, whether those are automated or not.

Notifications when something interesting changes in a key metric or at all-hands meetings for your company, like my manager does, like have a reminder in there, this is the place to look if you have this question. This is where it lives. I think it is a really important part of keeping dashboards alive.

And I think that people find that incredibly useful, and I, for one, am always grateful. When people gimme little reminders of like, here's where that answer might be that you're looking for, so that I continue going back to it.

Yeah. Incredibly useful, and there's always a place, certainly, having come from a team that produced dashboards, always a place for dashboards. They have a special place in my heart. But I think it's also fair to acknowledge that dashboards probably have some limitations. You would typically, I guess, use them more for that exploratory side of things, you're looking for items, KPIs that are maybe going outside of appetite.

Things that are above goal, below goal, et cetera. And so therefore, once you have found those things, you're gonna probably wanna move on and move away from the dashboard and bring it to life in some different way. Almost transitioning from that exploratory side to the explanatory side of analysis. And I think once you get into that side of things, you've got a whole new range of options that have been provided to you.

How might you communicate the information? Who is it going to? What are you looking to achieve with that communication? Which chart? Indeed, should you choose. And when it comes to choosing the visualization type to communicate your data, there are a number of different options. And I think one of the things that we always talk about is that there's no necessarily one right way to visualize your data.

And I think in some ways that can make it a little bit more confusing. Not having this strict, oh, I've got this type of data, therefore it's gotta be this type of graph. But one thing we always say is that, once you do choose your appropriate data visualization, can you take steps to help you reduce some of that redundant information that our tools might provide to us?

And whilst that's a great first step, we do look to approach that and layer things on. But I think it's also important to acknowledge that, whilst these charts might be technically correct, they're not necessarily. That's effective either. And they don't necessarily help get our insights to our audience in the most efficient way.

And so I know you've got some interesting thoughts on some of the differences between what might constitute a technically correct chart and what actually is truly impactful for its audience.

First, I have to comment on what you were saying about, like, nothing is really the right chart. Just another experience from teaching is that I felt like a big part of my job teaching statistics and visualization, was teaching comfort in those gray areas, which is hard because I think in a lot of courses, especially in science and technical courses.

Students are really inclined, and I certainly was, to want a flow chart of if this, then do this. If the sample size is greater than 30, use this test. If the sample size is less than 30, use this test. And that is really. not the way that stats or analysis, or visualization are. It's like everything is a gray area; everything is on the table. There are 12 different options, and choosing between those can be really challenging, and there's a lot of nuance. And to get back to your question related to that, it's okay, maybe there is a technically correct way to visualize data, but that might not be the clearest way to bring the most value to viewers.

And I'll give an example that I think is really common, and it's with a chart type that I love because I really am a fan of the essentials. Like I love a line chart, I love a scatterplot chart, I love a bar chart. I love a histogram, so a histogram. Very often, with business data, you get like very highly skewed, often very highly, positively skewed data, with the bulk of your information centralized around lower values.

But then you have a few outliers, you have a few huge whale clients that are paying you tens of millions of dollars a year. But everybody else may be in this smaller bin, where they're paying for the lower tiers or something. And that's a really common distribution for a lot of businesses, whether it's their product sale prices or the client revenue they have, or whatever.

And what happens if you try to show all of that data on a linear scale in the same chart, is often what you'll get is the only thing visible is one bar on the far left hand side and everything else is a bunch of white space and there's technically data there, but you can't see anything else besides this one bar that is just reflecting that strong positive skew.

Now that the chart is technically correct, right? Like, technically, that is the truth of the data. But then we have to ask ourselves like but what is beyond that? This is highly skewed data. What is a viewer learning from this? And is this a chart that is like, interesting for them to wanna learn more, and are they able to learn more?

So, as an example, one way that we've tried to address this, balance that, like usefulness and engagement while still keeping the information accurate and observable, is by trying to wrangle a histogram. To not mislead people into thinking that it's not positively skewed, but to allow them to see more about the data that has been compressed into a single bin.

There are a lot of options for this, right? You can log, transform data, which is asking a lot for people to try to interpret that and be happy, and draw the right conclusions about that distribution when things are log transformed. What our approach has been, and again, it's not right, is that one approach is we've said, okay, we are gonna focus the chart on this lower tail where most of the data lives, so that the default is to show a viewer the distribution of the majority of the observations. But we don't want them not to know that there are observations that exist in that upper tail that they might want to explore further. So we also have a visually distinct bar indicating the number of observations that live beyond this focused area that we are really focusing their attention on is the default.

And that's an example of playing in that gray area of technical correctness and usefulness as a default to show the bulk of the data and how that's distributed, but also making sure that a user also has visibility into what else is there, if they wanna explore it further. Again, that's a decision.

And is it right? No, because there's no like right way, but it's a way that we're trying to strike that balance between what is a more useful default visualization, while still making sure that people aren't under the impression that nothing else exists that they might wanna explore in a different way.

I was wondering if we were gonna get through the podcast without saying it depends, but it appears we haven't, because, to your point, it really does depend on a number of different factors. I like the approach that you're talking about. There is maybe a little bit of sparing color to highlight one bar before.

Maybe drilling into it a bit further, I've also seen this happen where we've got maybe time-based data as well, and you've got this huge buildup, well, you're doing it by month or by quarter, and it looks like a flat line. And so, well, what's the story there? But the more you break it down, the more you begin to see that actually there's some interesting weekly patterns or daily patterns or hourly patterns depending on the spread of the data.

So yeah, it's not so much about the right chart choice or the appropriate chart choice. It's the level of data that you communicate as well can certainly lead to that. I like the comparison there, what you write comforts in gray areas. That always reminds me of my children's homework that they do. I've got one that loves English because English is a bit more loose in terms of being right or wrong, you can be correct with a choice of words that may mean or may be similar in meaning to something else, whereas I've got another one who loves math because it's exact, you're right, three times three is nine, it's not eight, and it's not 10 it's definitely nine. Whereas the other one doesn't quite like that approach. He likes to be a bit looser with his answers. Yeah. And by the way, we're also huge advocates here of the essentials, as you call them. I think there's a huge amount to be said for bars, for lines for, we use quite a few dot plots as well nowadays, so they're pretty common. Slopes as well as the lines with two points. I think all of these, ultimately, what are we trying to do here? We're trying to get the information to our audience in the easiest way, and we're trying to let those insights shine through, aren't we? And so, if building up complicated charts or trying to just test ourselves from a personal development perspective by creating something new just for the fun of it, that's not always gonna help land the key message.

And I think, certainly, when it comes to the accuracy of charts and the right chart. The word that I consider to be the best word is appropriate. What's the most appropriate way of sharing this message now? One thing that has come up a few times during the course of this is collaboration and talking with the business.

We've touched upon it in terms of ourselves working in data, how we talk to the business. Maybe it's a bit of an undervalued skill. The story I mentioned at the beginning, one of my favorite examples of the power of cross collaboration or working with other teams. But it does always surprise me, and I still hear it nowadays, actually.

I dunno if this is true with you, Alison, that I think the business or businesses can still see data teams as just service providers, and I'm sure you've probably seen some great examples and probably some horror stories as well in terms of how that cross collaboration can really enhance or completely destroy a visualization or a concept that's trying to be built.

And it’s unfortunate when an incoming request to a data team is only seen as a ticket that they have to check off. Instead of an opportunity to build a relationship between the data team and stakeholders or managers or whatever team they're trying to build something useful for, because there's such value in that cross-functional collaboration to learn.

What other teams are interested in and what their level of data literacy is, I think, can really inform, across the board, the types of visuals that data teams like choose to create and how they create them and what level of annotation they're gonna add. It's really unfortunate when it just becomes this ticket list check-off done for that reason. There's just less osmotic learning that can help build the business together and get more buy-in from everybody in terms of what every team is creating. But also, that approach often leads to ineffective visualizations and dashboards being created. And frustrated end users who don't trust or feel any connection or ownership over the end product.

Which I think is another reason that sometimes dashboards end up going unused. I think it's really critical when people are building dashboards that you get feedback from the people who you are hoping will use this thing that you're working so hard to build. It's not like you've made a whole draft in your little silo and then you drop it in their lap and say, This is ready for review.

When you do that, a person, when they're reviewing it, can feel like, well, how much this is built, how much opportunity really is there for me to make suggestions? I don't feel like I've had a part in this. And I don't know the context behind the decisions; I don't know where there would've been opportunities to go a different direction. They might not even realize there were opportunities to display data in different ways.

What I am really excited about are tools that make it easier for people to have meaningful collaboration throughout the entire process of dashboard development, which makes it lightweight for the people who are requesting the dashboards to get in the same place where a dashboard is being developed, to see the context, and to add notes so they're not separated.

From the dashboard development process that they can actually be in there with you as you're doing the work to see what the other options were, to add notes directly so you don't have to question what they were talking about. And so that when you get to the end point, first draft, they're already, like you were describing with the champions on the team that advocated for your dashboard, that they also feel like this is something that I have helped create that I feel some ownership over, that I will defend, and that I know has value because I've seen it grow up, because I have seen the options, and I've been involved in the discussion. And I feel empowered by this thing because I understand what's under it, the decisions that have been made, I have participated in the making of it, and that's why I feel so good about this thing that I am looking at now that I will continue to use and advocate for.

So I think there's a lot of value in collaborative analytics for keeping people not just in the loop, but also. Helping people be direct participants in the development throughout the entire process, instead of just an end point, and share any feedback, at which point I think so much has been lost.

Yeah, that again reminds me of something quite a funny story where I was I was very confident, and I think it's interesting, isn't it, to dive into the psyche of the analysts, let's call them, who don't necessarily reach out for feedback. Yeah. What is it about? That process that maybe people are a little bit reluctant to get.

And I think from my personal perspective of this one story was, I was so, so confident that I'd done the right thing. And this was more of a pack refresher big annual performance pack that we put together to present. And I'd done this for about four or five years. So I was pretty comfortable with the process, pretty happy with how things would go.

So I just went off by myself and produced this pack, big old thing, like a hundred pages. And once I built it, I just quickly, casually took it over to my manager, plunked it on their desk, and said, What'd you think of this? And then I went back down and sat down and got on with my next job. And then about an hour or so later, he came back with this huge list of things, suggestions.

And at the point in time, I was pretty annoyed. I thought, well, why are you bothering me with this list? I've done it right. I'm comfortable with the process. But of course, really it was on me. I didn't put myself in any great position to get feedback. I didn't really give him a sense of. What feedback I wanted.

I think that's an important part, isn't it? Because if you just go, what do you think of this? Well, that gives the person free rein to comment on everything. And that might be design choices, colors, fonts, sizes, all of that kind of thing that you might have absolutely nailed down. You don't need to change at all.

And then of course it opens it up to other things as well. Different ideas that they might have, different suggestions that they think they might wanna evolve, that it's not simply a refresh from previous years. It's moving on. And see, I was pretty perturbed by this. List of changes that had come through, thinking that he'd only really done it to justify his place as a manager.

But of course it was completely my fault. I didn't allow the right amount of time to get the feedback. And yet there were many things that I'd probably do a little bit differently going forward, but it is interesting to think about why people might be nervous, people might not want to.

Feel that their work is being critiqued. I dunno what other thoughts on why people don't ask for feedback? 'cause it is such a great thing to try and get, I believe.

I think there are A number of reasons. I think you're right that feedback can be scary. I think it's scarier the longer you wait to get it. And so, it is like, the more scared you are of feedback. It doesn't feel like you should, but the earlier and more frequently you should try to get it.

Like when you can get feedback earlier on in little bits, that makes the process of getting feedback a lot less daunting. I personally still make this mistake sometimes, where I'll think like. Ooh, I've actually gotten farther down this process than I should have before requesting feedback.

And I can feel the anxiety building in terms of this could mean really major changes. And I really wish that I had just done two check-ins at earlier points, because then I would not have this feeling. So I think that's the hardest thing to train yourself to do when you have that type of anxiety.

But it is incredibly valuable to force yourself to like, get earlier and more frequent feedback because it actually makes it much less scary, and you can expect fewer huge, more terrifying changes later on.

It is a balance as well, though, isn't it? Because of it, I think some people think that I don't wanna give, I don't wanna ask for feedback too early because. It. It's not in the state that I'm proud of, let's say. And people, they might just give the feedback of, oh, you haven't really, have you put any effort into this yet?

Or have you really considered this way of laying it out? Because it doesn't feel like it's quite there yet. But I think that's all in the positioning, isn't it? If you say to the person that this is just a real rough, it could even be a sketch. Of course, you don't need to have it in the tool. It could just be a very quick drawing or an idea.

But this is just a very quick thing, and just get a sense of I'm on the right track here on the right path. But I do wonder whether people think they have got this sort of personal pride, if you like, of wanting to get to a really good place before they then provide feedback. But of course, to your point, that's probably far too far along the journey, and it's a little bit late at that point in time as well.

I just feel this so strongly, and I have had to learn this the hard way because I feel like if you're waiting until you feel great about something to share it, it's too late. Like I, I am, and I think that's. Easier as you move on in your career. I think when you're a, like a, just getting started as an analyst or you're just getting started with a new company, it is a lot scarier.

So I totally agree that, like early on, you might have more statements and disclaimers, or like just getting started, you need early feedback. This is rough. Not what this will look like. I think that's totally expected. And then as you move on, I think there's like no disclaimers needed. As you get to know your team and your team gets to know you, and be like, this is early and terrible, please help.

Like, I think um, it becomes actually a really fun part of kind of building rapport and trust with a team is being able to put really rough stuff out there and know and trust that your team will. We will know what you can do and just be ready to help at whatever level of your project you're currently at.

And I don't think I've ever encountered a scenario where, after having received feedback, I felt like the thing I've produced has been worse. So, in summary, in short, there feedback is useful and does make your work better. In pretty much all cases. I've certainly seen that throughout my experience as well.

So making sure you take on board the feedback is no worse feeling for the person that's provided feedback to see your report, dashboard, visualization slides, whatever you've produced, and then go, well, hang on a minute. I, I. I told them that there were probably better options to consider within that particular piece of content.

And it's not been accommodated, not been factored in. So if you do ask for feedback and you get feedback nine times outta 10, it's gonna be good feedback, I imagine. And therefore, you're gonna want to think about acting on it, at least giving the person who provided that feedback. A good sense of, yeah, their time has been well spent.

Yeah, absolutely. I think I'll just add a small piece to that is even feedback that you choose not to include it. It is incredibly useful feedback, right? Because it helps you to understand a little bit more about the people that you're creating something for, and that's an opportunity to think like, oh, I didn't realize they were thinking about this way.

And that's a valuable thing for our data team to know. And maybe there's an opportunity for education like you were talking about, you would do those little deep dives into a metric. even feedback that doesn't get used in a final product. It can be really valuable in terms of understanding the level of understanding of your team, what they're looking for, and their background.

So I totally agree that all feedback can be really useful in some way.

Yeah. And I guess it provides a sense of options, doesn't it? So like you say, even if you're not using it or considering it for this topic, well, if it's there somewhere, and I like the point by the way that you said around some of the more. Automated ways of collecting both feedback and comments?

Some of the tools that we've got at our disposal, I think, have been helped by the fact that a lot of us are remote working now and not necessarily at each other's desks, but the ease of being able to just apply a comment and send it over to the person that's producing this information can make things very much more dynamic.

But it builds up this. Repertoire or range of different options, isn't it? And ways that you might consider doing it in the future, even if it's not gonna be done there at that particular point in time.

Absolutely.

Good stuff. Okay. Well, we're coming quite close to the end now. This is phone bias, so thank you, Alison.

And I think also, let's wrap things up by saying, well, okay, we've talked a lot about collaboration, we've talked about feedback, we've talked about making sure we speak to the business and acting more of a consultative way, understanding that. Talking to the business is a skill that an analyst should have.

In addition to, or complementing their skills, they've clearly got in the technical space, making sure that they have both sides very clearly ticked off. But from your point of view, what does success look like? You know, we've done this, we've got feedback, we've iterated through, we spoke to the business, and we've produced something.

And that could be a presentation, it could be a dashboard, or a report. What does it truly look like when we've got this success? We've really nailed it, if you like, in terms of doing this cross-collaborative effect.

I think there's a business answer, which is that if you've made a good dashboard, people can make good decisions faster. I think that when it comes down to core value, that is the primary business goal. But I think there's so much around that we can hope for in terms of. People are being empowered and excited about using the work of data teams to make better decisions. And that requires a lot more than just, here's the dashboard, this has all the information you need in it. So I think real success is not just that people can use a dashboard to make. Better decisions faster, but they also have a sense of empowerment and agency for the data tools that they trust.

Not only what they're looking at and the decisions that they can make, but they also trust their understanding of the data. So dashboards and collaborating with data teams can also be an incredible way for anybody. In an organization or in a company to feel like they are building their data literacy, their understanding the context around the company data so that everybody can be lifted up in their understanding and decision making with data together so that they can make better decisions, but also feel like a bigger contributor to the team overall, which I think is a really exciting part of what dashboards and data teams can offer.

Definitely, yeah. The aspect around, can we make a decision off the back of this information, I think, yeah. It is crucial, and whilst using dashboards, you might be a little bit more. So there may not always gonna be decisions off the back of it if they can be impactful enough or useful enough that we can begin to understand the different changes in those particular KPIs or metrics.

So then bring them to life via a different method, perhaps taking the information out of the dashboard, creating more of a data story with a presentation, and hopefully motivating an audience to act upon that really can be crucial. I think for me as well, it's bridging that gap.

Between the functions, the services, and the business, and trying to really close that and almost feel like there's that real, true sense of relationship there. There was a term that was coined again back in the day called Trusted Advisor. And so rather than just seeing the data team as this. Here's a ticket to your point, here's a ticket.

Go off and do the work, and then provide it back. Actually, having that conversation, here's what we are looking for. Oh, why? Why are you interested in that? Oh, 'cause we think we wanna see this. Oh, why do you wanna see that? Having that real back-and-forth conversation, I think that's really where you begin to see.

Great things are being produced, and to your point, again, things are being acted upon as well. Okay. One more question, Allison, for you, if you don't mind, humor me. And if you could have or share one piece of advice with either your younger self, or if that's a little bit too deep or philosophical, don't worry.

Or let's call it any other aspiring analysts. Yeah. What would it be? One, one piece, one tip for anyone maybe venturing out in their career in data.

It would be that asking questions is not just a valuable thing for me to do. That's an incredibly valuable thing for the person that you are asking the question to. I think that I almost felt selfish, taking time to ask questions, and I've tried and had to learn to reframe that to like know me asking a question, yeah, that's gonna be useful for me, but that's also a, kind and useful thing for the person receiving the question because that gives them important information about the way I'm thinking, or a friction point that they might be able to solve or something that they haven't.

Thought about it clearly. So I think that I have really had to learn that asking questions is not a selfish thing. It is not a time-wasting thing for anyone who questions, no matter what level you're at. And I would say, especially questions that you might be tempted to think this is a stupid question.

Those might be the most valuable questions for other people to hear because it's really important that they understand how other people on a team are struggling, or don't understand, or are thinking about something that helps everyone to do better work together.

Into the innocence of children, and they're just constantly asking questions. You know, why, why, why, why? All of that kind of structure can certainly help. And I think, let's be honest, who doesn't like answering questions either about their projects, their topics, or themselves? I mean, everyone, I think, anyway, maybe I'm wrong, loves answering questions about themselves.

So people like to receive questions on your point too.

Yep.

Fantastic. Thank you very much, Allison. That brings us to a close for today. So again, just like to say a huge thank you for such an enjoyable conversation. I knew it'd be a good one, having our pre-podcast chat, and it's certainly lived up to that.

So I hope everyone listening enjoyed the show. Thank you very much for listening, and until next time, goodbye. See you later.