Data Knowledge Pioneers Episode 3: Broken Data / Business Workflows

Workstream.io CEO Nick Freund is joined by two fantastic data leaders and practitioners to discuss one of the most common breakdowns in data: the workflows between data teams and the business teams they support.

Today's guests are Mode Founder Benn Stancil, and Danielle Mendheim, the Director of Analytics & Strategy at Dr. Squatch.

Learn more about how they envision the problem with these workflows - all the way from the intake of requests, through executing and sharing assets back out with their team - as well as the solutions they've implemented to counteract this breakdown.

Listen on Apple, Spotify, or YouTube, or read the full transcript below.

Transcript

[00:00:00] Nick Freund: So welcome back to Data Knowledge Pioneers, presented by Workstream io. And again, we're exploring how organizations create shared consciousness around your data. I'm Nick Freund*, and I'm speaking with leaders and data practitioners about the acute problems folks experience in creating, curating and disseminating knowledge about your data.

[00:00:31] And today specifically, we're diving into the problem of broken data and business workflows. There's lots of form factors to how data teams and business teams work together, and so we're gonna talk a little bit about where that breaks down. Joining me are two awesome data leaders that I'm really excited to explore this topic with.

[00:00:53] So, first off, we have Danielle Mendheim, who's the Director of Data and Analytics at Dr. Squatch, which is one of the fastest-growing natural men's soap and personal care companies in the country. And we also have Benn Stancil, who's the Co-founder and Chief Analytics Officer at Mode Analytic, which is a modern BI and data science platform. You may know him from his Substack. So, first off, Danielle, Benn, just thanks so much for joining me today. 

[00:01:19] Danielle Mendheim: Thanks, Nick. 

[00:01:20] Benn Stancil: Good to be here. 

[00:01:21] Nick Freund: The way I wanted to start was just to see if we could define and just talk about the problem. What is it that we mean when we say that workflows between data teams and business teams are broken? At least from my perspective, every data team has some way that they use to manage requests from other folks in the business, or support work. But no one's typically happy with what ends up getting implemented. And so Danielle, I'm just wondering, is that how you see this problem? Like, are there other ways that you've seen this problem manifest in your experience? 

[00:01:59] Danielle Mendheim: Yeah. One, it's definitely a problem. I feel like it's probably one of the biggest problems that we face at Dr. Squatch is, where are requests coming from, and how do we handle all of those different requests? I think the biggest thing is that they come from everywhere. And they're not really defined as what is actually a request, and when does it make the actual sprint? And when is it just simply a team asking the question? And so it's figuring out, how do you separate between those things, that has been the biggest challenge for us. 

[00:02:33] Nick Freund: Benn, from our private conversations, I know that for a long time you've overseen internal analytics stuff at Mode, and you've been in data your whole career. How have you experienced this problem in the past? And does what Danielle said resonate with you?

[00:02:47] Benn Stancil: Yeah, certainly. And I think it's kind of broken everywhere, I would say. Where it's broken on the intake basically of, how do business teams interact with data teams? There's all these sort of – we have a Jira form to fill out stuff. Or, here's the process. Answer these questions and we'll answer your ticket. But nobody really follows those things. There's always like, “well I have a guy that I DM,” or, “this analyst is the one that I'm friends with, so I'll send him a Slack and she'll help out.” So there's this intake problem that's a really big issue. I think this actually doesn't get managed terribly well by most data teams. Some have sprint processes. Some don't. Because these things don't actually get formalized often in tickets. They just kind of get: “Oh, I'll take a look at this,” or, “can you pull this thing really fast?” There's not really a formalization of how that work often then gets done. 

And there's a big problem with how you share it back out. It's a thing that often those answers get delivered in the same way they get sent in. So, maybe it's on the ticket. Maybe it's in a DM. Maybe it's in an email. Maybe it's in a slide deck somewhere. Maybe it's a conversation. Nobody knows where to find any of it. It doesn't exist. It's all ephemeral. It sometimes exists in documentation. It's written down. Sometimes it exists in Slack messages that are meant to be searchable, sometimes exists just nowhere. And so the whole thing just is all kind of chaotic, figure out how to get answers however you can. And I think a lot of business folks end up basically developing habits that make sense around just: my job is to try to get an answer however I can, and I'll try five different ways. And whatever one gets me the answer first is the right one. And I'll keep doing that until it doesn't work anymore. 

[00:04:16] Nick Freund: Yeah, totally. Benn, maybe it was last year, I feel like in your Substack one of your spicier takes was, the only way to measure a data team was by how fast they provide answers. I can't remember if I'm remembering the takeaway from that article right. Am I misquoting you? Or is that you just being intentionally controversial? Or is there truth to that? 

[00:04:36] Benn Stancil: No, so it's a little more nuanced than that, I think. I think it's basically, the way a data team should assess how well they are doing, is how quickly someone makes a decision. This doesn't quite reflect that there's a problem here where this probably encourages a lot of weird ad hoc back channel-y dynamics that aren't great. But the point in that was that, if you are a data team and you get asked a question by some stakeholder, you basically want to get them to the point where they can make whatever decision they need to make to move forward as fast as you can. It's an imperfect heuristic. But the reason to me is, your job is to basically convince them of something. They are your gate in saying whether or not your analysis is good. If you convince them this is good, then okay, it must be, they're the ones who are sort of next on the line of, am I making the right decision about where this marketing campaign goes? What products to build? Or those sorts of things. And so, your job is basically, as quickly as you can get them to the point where they're comfortable making a decision. So a lot of analysts, I think have a tendency to sort of overanalyze things. It's not to cross every T and dot every I. It's more, all right, we have this question. If we can get this person to a point where they feel comfortable making a decision, then we have done our job. You know, it's not our job to sort of make a legal case for it. It's our job to help the person who has to make a decision, be confident in the decision they have to make. 

[00:05:52] Nick Freund: Now, so Danielle, with that, you were mentioning at the outset that you get requests from all over the place, and what ends up in the sprint versus how do you go back to people. What's your methodology within the team today for managing this kind of inbound chaos and prioritizing it? 

[00:06:13] Danielle Mendheim: Yeah. I loved how Benn listed like 20 different options and I sat there thinking, shoot, we definitely do all 20 of these. I think the biggest one, the intake process is so convoluted in and of itself. Because you not only need to know, how quickly can someone make a decision off of this? It's like, are they going to make a decision off of this? Why are you asking for this? How does this connect to every other thing in the business? There's so much to that original question. Whether it's from Slack or if it's from a JIRA request, or whatever that might be. I think what we've tried to do is, we've tried to start to teach every analyst to ask the top key questions. What are the top two to three questions that you can ask this person to quickly identify, do you need to push them to make a formal request? Can you quickly answer it in less than five minutes? Or does it need to make your board, and it's not even an individual request? And so I think it actually goes back to, Nick, not having the perfect process for those intakes. But instead training individuals who can really quickly decide where that request falls. Because I think you're never gonna have the perfect process. That would be kind of my pushback. 

[00:07:30] Benn Stancil: So, I have a question on that actually, Danielle. Which I never thought of until you're answering that. 

[00:07:36] Danielle Mendheim: Go ahead. 

[00:07:36] Benn Stancil: I don't have an answer to this. It's a genuine question. Why are data teams so bad at this? There's so many teams that have these intake things. IT teams do it. Engineering teams do it. Design teams do it. Everybody has a ticketing thing. And you don't hear about engineers being like, “it's chaos.” Is it because data stuff is fast enough to answer that you don't need it? Like why have we failed so miserably at this, when other teams have figured this out? 

[00:08:01] Nick Freund: If you believe other teams have figured it out, but that's a whole other separate topic. 

[00:08:04] Benn Stancil: It seems better. 

[00:08:06] Danielle Mendheim: Engineering. Engineering would be the only other team that I'm thinking of where – in our terms we call it the web team – they are better at it than us, is I think what Benn's highlighting. Not necessarily all other teams. I think it comes back to: stakeholders know what to ask the web team. They know I want this feature change, or I want this thing to happen. Whereas with the data team, they come to us with very, very vague business questions. And because of that, it's hard to know, is this actually something that makes the roadmap? Does this make the sprint? Or is this literally a thirty second answer? And sometimes we turn thirty second answers into entire roadmap projects. And sometimes roadmap projects should have been a thirty second answer. And so I think it's because the stakeholders don't know what to ask of us. Because we haven't done a good enough job of actually understanding what they're trying to do with that. That’s to me the core problem, is that we just do a really bad job in the data space of understanding why, and not turning something into a bigger project than it needs to be, or vice versa. I'm curious to hear, Benn, what you would say of why data teams stuck at this.

[00:09:28] Benn Stancil: I think that it’s probably because the range of sizes of things is so huge. And it's a little bit unknown, where you don't know if you're gonna be like: I'm curious about this thing. And you're like, I don't know, maybe that'll take me five minutes. Maybe it'll take me a month. I don't know. 

I've never thought about it in this angle. But it’s I think one of the things that does somewhat of a disservice for data teams. And Mode is a BI tool that has focused on ad hoc analysis in its inception, now it is more of just BI, and has both more formalized BI and ad hoc kind of folded together. But its initial work was ad hoc work. And I always sort of hated the term. Because it has this very ephemeral – it's scratch work. It's this one-off, pull me an email list type of thing. But it's not actually... 

[00:10:16] Nick Freund: There's a negative connotation.

[00:10:19] Benn Stancil: Yeah, it's like my ad hoc work is something that's kind of throwaway, you know?

I have my ad hoc scratch pad. And then I have the thing that I'm building. And the ad hoc thing is not lasting. So that's how we have to describe this work. To me it does a bad job of reflecting the value of it. Because some ad hoc work is, “we need to do strategic analysis to figure out if we should acquire a company.” 

That's a really big decision. But it's all sort of folded under the same umbrella as, “we need to figure out how many users signed up last week so that we can make a reference to it in a sales call.” And it needs to be done in five minutes. To me, if that's how you describe the work that comes into a ticketing system, is you have one term for all of it, and it's not literally the terminology. But it's the fact that those two things are all tossed in the same bucket. It seems like a very, very hard thing to manage requests. Because somebody can easily send you a DM being like, do this thing in five minutes. You're like, okay, I wanna be helpful. But it also could be a huge project. 

[00:11:22] Danielle Mendheim: It's funny you actually used the phrase ad hoc. That used to be one of our Epics on JIRA up until about six months ago. And I was like, I'm done with this Epic. I can't deal with this vague terminology of ad hoc. This is unhelpful to me. Even in the planning purposes, or repeating back to execs what the data team is doing. This catchall bucket is not sustainable. And so we actually retired that Epic. And we ended up calling it vastly different things. And there were like seven different Epics that came out of that. Because, like you said, Benn, it could be massive changes for the entire organization that we're driving with those particular insights. Or it could be a direct mail list that needs to be sent out, because we're gonna send direct mail mailers to a bunch of customers in the near future. I think for me it's the understanding, who in the company is asking for this? Why are they asking for it? And then really quickly assessing, I get their timeline, but where does it fit into the bigger picture of what our deliverables need to be for the entire company? And it's getting everyone, even my most junior analyst, to think in that way. That has made it a lot easier. Because then we can accept requests from anywhere. Let's stop saying you have to fill out a form. We make things too complicated on the data side. Let's take it from Slack. Let's take it from Workstream. Let's take it from anywhere. But let's really quickly figure out if it's gonna be that thirty second task. Or if it's gonna be that like, really long-term thing, and it does take us time. Like we need probably a little bit of time to figure that out. But what does that look like? 

[00:13:01] Benn Stancil: Yeah. And actually, another thing that made me think of that is a way in which data work is generally different than engineering, that might have some of this effect too. 

A lot of data projects can be done by one person. You can DM somebody with the expectation that they can do it. Whereas, if you're like, build me a feature, you sort of know you can't DM one person that can do the whole thing. Every data project basically has one person to ever talk to, unless it's an infrastructure thing or whatever. But if you're a stakeholder, you basically have one person that I talk to. This is my analyst, or whatever. 

Benn Stancil: Whereas in engineering, there's more of a sense of, there's an engineering team that I have to go through. Not this one person.

[00:13:46] Danielle Mendheim: Or even a PM, and I have to go through the PM. I can't just go to the engineer. I will say, we have tried to – and this isn't a secret solution – but I have asked teams to stop DMing my team. And I'll say it in a much more nuanced kind way. And we will make very small shared Slack channels. Where it's just the three stakeholders on that particular function. Not even the team. And the analysts that they normally go to, and me and maybe one other person from our team. And it makes it so that there is a bit of that accountability. I'm not just gonna ask for anything, because there's five people on this Slack channel. It can't just be a DM. But also they feel way more comfortable to ask anything and everything, and then I'm able to quickly say, “Hey, our team actually doesn't have time for this,” or, “Hey, yes, we actually do, this is really interesting. We'd love to work on that.” 

And so, instead of having, the Marketing team and Data team are all on one Slack channel, we try to keep it very condensed. And that has allowed for a little bit of that catchall category to feel less so a, “Hey, can you work on this?” behind the scenes. But yeah, it's tricky definitely... 

[00:14:59] Nick Freund: So Danielle, to dig into that, is that broken out by topic, or is that just organically based off of the interactions you're having with other folks? 

[00:15:07] Danielle Mendheim: So, each of our teams at Squatch are very, very small. So, we'll have the Marketing umbrella. But then within marketing we'll have the Lifecycle team. And there's five of them. And then within the Marketing team, you have the Marketplaces team. So, their initiatives are Amazon focused. And there's three of them. Or whatever that might look like. And I have a different analyst who focuses on each of those functions – not necessarily one analyst to function, but one analyst owns that function, and might own two or three other ones. So, it means they know who their go-to person is. But they also know that with the go-to person, it can't just be a DM. It needs to be a shared space for them to ask that particular question. Because other people on the team might have the same question. And they use Workstream in the same way. Where we use those conversations in sort of the same way as that shared Slack channel, as well.

[00:16:03] Nick Freund: Very interesting. So, Benn, to go back to your original question. So, what we're saying is, part of the reason we think data teams are particularly bad at this is because, hypotheses are, one person can own the whole project. Danielle, I'm trying to remember what your initial point was. 

[00:16:19] Danielle Mendheim: No, it's okay. I think it's that stakeholders don't know how to ask. Like, stakeholders don't ask the right thing. 

[00:16:26] Nick Freund: Yeah. 

[00:16:26] Benn Stancil: Yeah. It’s vague. I guess in product or in engineering, there is a sense of, here's a ticket of what I want. But in data it's a much vaguer, “help me solve this,” that again can be a very narrow thing. And it's not a stakeholder's fault. It's just that's the nature of the load. Because it's a research problem. 

[00:16:48] Nick Freund: Totally. My only counterpoint to that would be, the typical bug or feature request in software engineering or software development. The role of a PM is to figure out what the real problem is, or what someone actually wants. And so a bug doesn't actually always mean that's what you should build. It just means this is a problem somebody's experiencing. And the same for a feature request. And so, it could result in something that looks a little bit different. So, there are kind of analogies there. Is it also on the – and not that you weren't saying this – but is it also on the data person to kind of PM that request?

[00:17:25] Danielle Mendheim: Oh, that's actually, when I say stakeholders don't ask the right thing, I feel like every single one of my stakeholders, who are awesome, would actually say, we ask the exact thing that we're looking for. It's the translation. But I think that's the problem, when it's one person solving the problem on the data side. The translation doesn't always happen. Because a PM, on the engineering side, has that whole widescape view, and the big picture view. And so they know how to figure out what is the actual solution to that bug. Whereas, if you're just asking one singular analyst, they might not necessarily have that view. So, I think things are lost in translation on that. And we don't do a great job on the data side translating. I really don't think we do. 

[00:18:11] Benn Stancil: Does that get solved at very big companies? I actually don't know this. If, say, your Airbnb or your Facebook, or whatever. And you've got a data team of hundreds. Do they have, in effect, PMs that are data PMs that are like data product PMs that are thinking about dashboards to build, or they're thinking more about, what is the technical surface area that we provide? Are there folks that essentially are closer to Project Managers that are the front lines of interactions for the rest of the business, but then ship work off to other data teams? Does that actually happen? I've never heard of that, but it seems like those organizations are big enough to function that way.

[00:18:50] Nick Freund: You would think. 

[00:18:51] Benn Stancil: Or maybe that's a terrible idea. I dunno. 

[00:18:52] Nick Freund: Yeah, I mean, I have honestly never really talked to a team that has done that. And I talk to teams about this stuff a lot, this specific problem. I've seen job postings every once in a while for Data Scrum Manager, Project Manager type of role. And some of the criteria will be managing requests and stuff like that. Just doesn't feel super common. 

[00:19:17] Benn Stancil: Yeah. And the Scrum Manager thing seems actually closer to what it would be. And I’ve never seen that for a Data person, and it's probably getting awfully expensive to have a dedicated person to manage your data Asana board or whatever. But I don't know, at big enough companies, it seems like maybe it's worth it. But maybe not. 

[00:19:37] Nick Freund: For my take, and I'm curious if the two of you buy this or not, and this is a slightly different twist of, Benn, your comment. Which is, when you think of maybe not the biggest Data Teams in the world, but most Data Teams, when you're thinking of their product slash engineering workflow, and then their support workflow, which is kind of what we're talking about, it's often that same team or the same people having to manage that, right? Which is a harder dynamic, versus, in a software engineering organization, normally it's a much bigger team. And so, you've got PMs to triage support, and it's not the same team doing everything, every sprint all at once. And so, I think that lessens the burden, and maybe it adds a little bit more opportunity for organizations. But I don't know if you think that's right or wrong. 

[00:20:35] Benn Stancil: I don't know. There a totally different direction you could go with this to me, too. Which is, in some ways, just embracing the chaos. There's a version of this where it's like, all right, how do we have everything super organized? And I think if that's what you think is right, yeah. That probably makes sense. But the further we go down that path of “we gotta have this structure, and this process, and this process, and this process,” there's part of me that's sort of is like, maybe the free for all isn't so bad. And we just figure out a way to like the free for all work a little bit better, if the alternative is some super kind of over-engineered process for making this work. Especially if the team is usually between 5 and 10 people, or whatever.

[00:21:12] Danielle Mendheim: I agree with that. Because I almost think having the approachability, that is the one thing that is often mentioned about our Data Team, is you're approachable. We feel like we can ask you anything. And I feel like if you create, if you try to fix too much of the chaos, you lose that approachability. I think, Benn, you highlighted at the end, there's the sharing back out at the end part. I think it's almost more important, was there a decision from this task, and how did we share it back out with the team, Than actually fixing the chaos of the intake. Well, the intake is the biggest burden on us, and we need to figure out how to handle it as a team. I don't think there's a silver bullet for how to tell the rest of the stakeholders how to do it all. That's my opinion. 

[00:22:03] Benn Stancil: Yeah. I worked on a data team prior to Mode that actually handled this reasonably well, in kind of a dumb way, where the team was big enough to do this. It was probably 10 analysts, data scientists. But basically we did something sort of like that. Where there was one person who, all the questions came in through one, what amounted to a Slack channel. There was one person whose job it was, where that was your week. You had your week on the queue, and you were supposed to answer questions you could. But basically be the person to follow up and be like, “Hey, we'll do this, we won't do it.” Whatever. You in effect were this Scrum Master type of thing. And the other consequence of that was, there was only one person who was actually staffed on working on this stuff, which meant they could escalate things if they needed to. But for the most part, we just didn't do that much of that kind of work, and the valuable work is the stuff we're gonna sort of assign in sort of clear ways. This stuff is, if it bubbles up, we'll do it. But it was a little bit more of an acknowledgement that this type of intake work is usually lower value anyway. So, we're just not gonna give it that much time. 

[00:23:12] Danielle Mendheim: Did you have the same person who did that at all times? Or was it a role that rotated?

[00:23:19] Benn Stancil: It was every week or every two weeks. And typically it was actually the job of usually the more junior person to do. So, we were hiring reasonably quickly. Probably hired a person once every two months, and usually it was like, your onboarding was a few weeks of just being clueless. And then a few weeks or a month of being on the queue. And then you kind of enter the rotation with everybody else. It was good exposure for onboarding, because you'd get asked questions across the business. You'd have to meet a bunch of people in the process. The questions usually weren't make or break questions. They were important, and they were valuable, and sometimes they'd be coming from the CEO, but they weren't the questions that would be like, if we get this wrong, we really messed something up. So it was sort of high visibility, low risk, in a lot of ways, types of things. And that actually worked pretty well, like I said. We had no documentation of it whatsoever, though. It was completely, once we answered the things, it was gone. But, in terms of intake, it actually worked pretty well.

[00:24:24] Danielle Mendheim: Yeah. Kinda like a help desk. But for the data side of things. 

[00:24:26] Benn Stancil: Mm-hmm. 

[00:24:26] Danielle Mendheim: Yeah, that makes a lot of sense. I think what I would say is, Dr. Squatch stakeholders are fairly good at using whatever tools they have available to answer their easy questions. And 80% of the time, their questions lead to awesome long-term projects. And so that's where, if it's just treated as a Help Desk, we often lose: “Oh my gosh, this was something that we really could have built an entire thing on, that would've revolutionized things. But I love the Help Desk idea. And I actually wonder – I wouldn't call it a Help Desk – but the rotation idea of having someone who's designated that week, to get comfortable with it. I love that. That's cool. 

[00:25:13] Nick Freund: You know, often when you talk with data folks about this part of their workflow and management of requests, it's one of the things that they find really annoying, or it's a not appreciated part of their job. And so, the question was, do you think that's a symptom or a cause here, right? Or do you disagree with that statement completely? 

[00:25:38] Benn Stancil: It's not something people seem to wanna do. It's not high on the list of, if they wrote their job description, they would not put this on their job description, in most cases. It sort of feels like most people treat it as a necessary evil, though actually, I've never thought of it this way. 

But actually, I think you may be onto something – a little bit of it is partly because it's poorly managed. Not because the work itself is bad. In a lot of cases, the work itself can be kind of fun, because you're bouncing around from project to project. You're learning different things. Trying new stuff. You don't actually have to stick on something for forever. You don't get buried in these frustrating, never-ending loops. It's fairly impactful in that someone asks a question, you can see the immediate result. Sometimes it's silly questions you don't wanna deal with, but if you get enough questions, you can find the ones that are useful. But there's something about it that feels very low man on the totem pole. You're just answering tickets. Like you’re a ticket monkey. And I think that... 

[00:26:48] Nick Freund: Yeah, it was when you were talking about “Oh, we throw the most junior person at this,” right? I’m like, maybe you throw the junior person at the task no one likes, you know? And I think to your point, when you think of like the Help Desk or the Service Desk, it makes you think, what am I, just a support agent at an airline, or like the annoying IT guy who comes and like, bitches at me while they tries to fix my computer, type of thing. Which is not, I think what most people think of or want when they embark upon their data career. 

[00:27:27] Benn Stancil: Yeah, and the junior part, there's another reason why maybe – and I don't know if we ever actually highlighted this – but in thinking about it, one of the reasons it worked probably for junior folks too, was because you didn't have to come up with the problems yourself. That there is also something of like, go sit next to the marketing team. Figure out what they need when they're not asking for it, it's hard. And this takes context. It takes some experience. If you're put on a queue, it's more proactive than people think. Cause it's not just answering a question as it's asked, as Danielle pointed out. People don't really ask questions in quite the right way, or they don't know what to ask. And there is a lot of back and forth there. But you're not quite as generative in the sense that you do have a big list of things to do. And you can just kind of follow those things. So, that was one of the other reasons why it worked relatively well for junior folks. 

But I think, I don't know, it does seem like it is maybe actually good work that we treat badly. Partly based on the things that I said, you know? It doesn't get a lot of respect. 

[00:28:28] Nick Freund: Well, I wonder, is that part of the problem? Not the result of the problem. Is it just because of all of these reasons: the social signaling, the last person on the totem pole, it's just annoying to be interrupted 20 times a day with the one-off question. Do we kind of intentionally do a bad job in this area? Or even subconsciously? And it leads to broader problems around how you interact with the organization.

[00:29:04] Danielle Mendheim: I feel like I love that statement, or I love this thought process. Because I almost feel like it goes back to what we value as data. I mean, I'm talking for myself here, but I'm grouping all of us together. What do I see as success? I'm like, “Ooh, I get the entire day to write Python and no one bothers me.” That is a successful day. But that actually does nothing for the company. What does things for the company? It's answering insights. It's caring about the way that these other teams think. It's giving quick answers here and there. And so I think it's the fact that these kinds of intake requests, they come with urgency. They need you to be available. They need you to respond. And so, it does get that bad rap. But if you can sort of shift your thinking, or make sure that you're not always doing that. Maybe it's not a hundred percent of the time, like Ben said – having a rotation to do it. It does become really rewarding work, and it's awesome. It's just making sure that that's not everything that you're doing all day, all the time. Because it is hard to constantly be available, and to always feel like, what they're asking for is the biggest thing on your to-do list. And so I do think it needs a little bit of a rebrand, because I think a lot of stuff that's really cool comes out of it, but it also needs to be the type of thing where we're not all doing it a hundred percent of the time. For sure. 

[00:30:29] Benn Stancil: There's another point to that, too, which I think is a good point: you have to work with other people. And that seems like lower level work. But I do think there is some group of folks that see the data work as: “I want to have a clear calendar and headphones on to just sit down and do analysis, and build stuff,” and somewhat of an engineering mentality of: “I need to be in a flow” kind of thing. And if I have to have these meetings or conversations or share stuff, then that's the peripheral work around the core work that I'm doing, and not sort of seeing that as the job. And that may be a demeanor thing. It may be a branding thing. But I do think a part of the job is all this stuff. And if you celebrate that, then you actually solve some of these problems, too. 

[00:31:26] Danielle Mendheim: And if you're good about not letting it get in the way. It's okay to not feel like you need to respond to that DM in 30 seconds. You should be responding within, you know, 10 minutes. But it doesn't need to be within 30 seconds. Because I think the things that we're working on are intense. We're thinking a lot. We are really thinking about whatever thing we're solving at that moment, and so to be jumping to answering a question, but then thinking about the long-term project, it's really hard to go back and forth between those. So, being really conscientious about when you're gonna be answering questions and when you're going to be thinking about maybe bigger projects that you're working on is really helpful, too. 

[00:32:10] Nick Freund: Yeah, for this specific problem or in general, how do you manage deep work time versus interrupt-driven, collaborative time is a big part of the problem. And to me, I think one of the reasons, specifically this is so challenging for data teams is, there's so many different hats that data professionals need to wear. There's the deep work engineering hat, where you have to be heads down focused for some long period of time to solve a problem, and then there's these other aspects of kind of product work, and prioritization, and scoping, and asking the right questions. On top of interrupt-driven, almost support type of work. And it's very few other teams at a company where the same team or the same person on the team is constantly having to switch between those different modes.

[00:33:09] Benn Stancil: Mm-hmm. 

[00:33:10] Nick Freund: No pun intended. 

[00:33:12] Benn Stancil: Yeah, and I think that's one of the reasons, too, that the rotational thing worked reasonably well, was because, while you had to be switching out of those modes over the course of weeks, it was typically not within the same day or hour, where it's like, “Oh, I have to keep my eye on some inbound set of things. I gotta respond to these messages.” It was like, no, you had the project you’re working on. And if you were on the queue, you didn't have a project that week. You weren't expected to do anything, and we effectively ran it like sprints. It wasn't officially that, but effectively we ran it that way, and if that was your week to do that, there was no expectation if you really didn't get much else done. It was like, “Oh, if you have time, fine, here's a thing, but we're not gonna care if you don't do that this week. Your job is to monitor the queue.”

[00:33:56] Danielle Mendheim: It's almost like, if we could find the sweet spot between having that queue, but also changing the mindset of the approach to those asks. I feel like those two things combined are where it lies. Cause I do think we need that shift in mindset of, this isn't the worst thing that you can do. This is actually something that enables others to do their job better. Which is the whole purpose of data. 

[00:34:22] Nick Freund: Yeah. I mean, Danielle, to that point, you've talked about really interesting projects or things coming out of these requests. Does that get highlighted for your team? Do you incorporate that type of opportunity into, I don't know, a mission for your team? Or how you talk to folks about a lot of team success and growth and all that stuff? 

[00:34:46] Danielle Mendheim: Yeah. Do you mean externally? Like with our stakeholders? Or just with the team itself?

[00:34:50] Nick Freund: I was thinking more internally within your team. You're trying to get folks riled up and excited about answering people's questions. But it could be with stakeholders too. 

[00:34:59] Danielle Mendheim: Yeah. How do we get them excited? I think, one, it becomes super relational. They have relationships with these stakeholders. It's not just transactional, is the way that I would phrase it. It's not just that they ask for things. I like to make sure that they know my team knows they can also ask the stakeholder for things. They can be like, “Hey, I'm noticing this. Can we do a project on this particular topic? It would be really fun and interesting for us, and we think that it has high opportunity.” And so it's creating that relationship. And then, I think, it is leading by example. It's having a good attitude when you do get asks, even for yourself. Because I think when you have that particular mindset, your team starts to have it. And my team is easy. They are all very interrelational with a lot of the other people on the Dr. Squatch team. Which makes it so simple to have those. And then it is that change in mindset of not just, when you're asked to do something, do that something. It's when you're asked to do something, ask why you're doing it. And then figure out if the solution is the best solution, or if there's something more that we could do beyond that. Because when you challenge yourself to ask the why, you either get a really cool project, or you get – I mean, no matter what, they're really cool – you get a quick and easy project. Or you get something that might be long term. So, it's that pushing for why is the stakeholder asking for this, and why is this important to them.

[00:36:34] Nick Freund: Very cool. Well, I think with that, that might be a good place to potentially wrap up. We've been going for a little while. Ben, Danielle, I don't know if either of you have any other parting thoughts on this topic before we wrap? 

[00:36:49] Benn Stancil: No, this was fun. 

[00:36:50] Danielle Mendheim: None for me. 

[00:36:51] Nick Freund: Awesome. Well, thanks again to you both for joining me, and thanks for listening, everyone. And hopefully we will see you next time on our next installment of Data Knowledge Pioneers. Where again, we're exploring how teams create shared consciousness around your data.

‍