Transcript
Speaker: So welcome back to Data Knowledge Pioneers presented by Workstream.io.
Speaker: And again, we're exploring how organizations create shared consciousness around your data.
Speaker: I'm Nick Freund.
Speaker: I'm speaking with leaders and data practitioners about the acute problems folks experience in creating, curating, and disseminating knowledge about your data.
Speaker: And today specifically, we're kind of diving into the problem of broken data and business workflows.
Speaker: There's lots of form factors to how data teams and business teams work together.
Speaker: And so we're gonna talk a little bit about where that breaks down.
Speaker: And joining me are two awesome data leaders that I'm really excited to explore this topic with.
Speaker: 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.
Speaker: And we also have Ben Stansel, who's the co-founder and chief analytics officer at Moda Analytics, which is a modern BI and data science platform.
Speaker: And you may know him from his sub stack.
Speaker: So first off, I guess, again, Danielle, Ben, just thanks so much for joining me today.
Speaker: Thanks, Nick.
Speaker: Good to be here.
Speaker: The way I kind of wanted to start was just to see if we could define and just talk about the problem.
Speaker: And so like, what is it that we mean when we say that workflows between data teams and business teams are broken and
Speaker: 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.
Speaker: but no one's typically happy with what ends up getting implemented.
Speaker: And so Danielle, I'm just wondering, like, is that how you see this problem?
Speaker: Like, are there other ways that you've seen this problem manifest, you know, in your experience?
Speaker: Yeah.
Speaker: One, it's definitely a problem.
Speaker: 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?
Speaker: I think it's
Speaker: 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 a question.
Speaker: And so it's figuring out like how do you separate between those things has been the biggest challenge for us.
Speaker: Ben, so like from our prior conversations, I know that for a long time you've overseen internal analytics of mode and you've been in data your whole career.
Speaker: Like,
Speaker: How have you experienced this problem in the past?
Speaker: And does what Danielle said resonate with you?
Speaker: Yeah, yeah, certainly.
Speaker: And I think like it's kind of broken everywhere, I would say, where it's like it's broken on like the intake, basically, of how do business teams interact with data teams.
Speaker: There's all these sort of like, we have a JIRA form to fill out stuff.
Speaker: Or like, here's the process.
Speaker: Answer these questions.
Speaker: We'll answer your ticket.
Speaker: But nobody really follows those things.
Speaker: There's always like, well, I have a guy that I DM.
Speaker: Or, you know, this analyst is the one that I'm friends with.
Speaker: So I'll send him a Slack and she'll help out.
Speaker: So there's like this intake problem that's a really big issue.
Speaker: I think this actually doesn't get managed terribly well by most data teams.
Speaker: Some have like sprint processes, some don't.
Speaker: Because these things don't actually get sort of formalized often in tickets, they just kind of get, oh, I'll kind of take a look at this or can you pull this thing really fast?
Speaker: There's not really a formalization of how that work often gets done.
Speaker: And there's a big problem with how you share it back out.
Speaker: Like it's a thing that often those answers get delivered in the same way they get sent in.
Speaker: So it's like, maybe it's on the ticket.
Speaker: Maybe it's in a DM.
Speaker: Maybe it's in an email.
Speaker: Maybe it's like in a slide deck somewhere.
Speaker: Maybe it's a conversation.
Speaker: Nobody knows where to find any of it.
Speaker: It doesn't exist.
Speaker: It's all ephemeral.
Speaker: It sometimes exists in documentation that's written down.
Speaker: Sometimes it exists in Slack messages that are meant to be searchable.
Speaker: Sometimes it exists just nowhere.
Speaker: And so the whole thing just is all kind of a chaotic, figure out how to get answers however you can.
Speaker: And I think a lot of business folks end up basically developing habits that make sense around just like, my job is to try to get an answer however I can.
Speaker: And I'll try five different ways.
Speaker: And whatever one gives me the answer first is the right one.
Speaker: And I'll keep doing that until it doesn't work anymore.
Speaker: Totally.
Speaker: Maybe it was last year.
Speaker: I feel like in your sub stack, one of your like spicier takes was like the only way to measure a data team was by how fast they provide answers.
Speaker: I can't remember if I'm remembering the takeaway from that article right, but like, am I misquoting you or is that you just being intentionally controversial or is there a truth to that?
Speaker: No.
Speaker: So it wasn't, it's a little more nuanced than that, I think.
Speaker: I think it's basically the way a data team should assess to me how well they are doing is how quickly someone makes a decision.
Speaker: And like this doesn't quite reflect the, there's a problem here where this probably encourages a lot of like weird ad hoc back channeling dynamics that aren't great.
Speaker: 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 didn't make to move forward as fast as you can.
Speaker: It's an imperfect heuristic, but the reason to me that is like your job is to basically convince them of something.
Speaker: They are your gate in saying whether or not your analysis is good.
Speaker: Like if you convince them this is good, then they're the ones who are sort of next on the line of like, am I making the right decision about where this marketing campaign goes, what product to build or those sorts of things.
Speaker: And so your job is basically like as quickly as you can get them to the point where they are comfortable making a decision.
Speaker: And so a lot of analysts, I think, have a tendency to sort of overanalyze things or whatever, like it's not to cross every T and dot every I. It's more of like, all right, we have this question.
Speaker: If we can get this person to a point where they feel comfortable making a decision, then we have done our job.
Speaker: It's not our job to sort of make a legal case for it.
Speaker: It's our job to help the person to make a decision, be confident in the decision that you make.
Speaker: So, Danielle, with that, like, how do you, you know, you were mentioning kind of at the outset that you kind of get requests from all over the place and what ends up in the sprint versus how do you go back to people?
Speaker: What's your methodology within the team today for managing this inbound chaos and prioritizing it?
Speaker: Yeah.
Speaker: I loved how Ben listed 20 different options, and I sat there thinking, shoot, we definitely do all 20 of these.
Speaker: I think the biggest one, the intake process is so convoluted in and of itself because...
Speaker: 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?
Speaker: Why are you asking for this?
Speaker: How does this connect to every other thing in the business?
Speaker: 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.
Speaker: I think what we've tried to do is we've tried to start to teach every analyst to ask like,
Speaker: the top key questions like 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
Speaker: for those intakes, but instead training individuals who can like really quickly decide where that request falls.
Speaker: Because I think you're never going to have the perfect process.
Speaker: That would be kind of my pushback.
Speaker: I have a question on that actually, Danielle.
Speaker: I've never thought of this until you were answering that.
Speaker: And I don't have an answer to this.
Speaker: It's like a genuine question.
Speaker: Why are data teams so bad at this?
Speaker: There are so many things that have these like intake things.
Speaker: IT teams do it, engineering teams do it, design teams do it.
Speaker: Like everybody has like a ticketing thing.
Speaker: And you don't hear about engineers being like, it's chaos.
Speaker: Like, is it because data stuff is fast enough to answer that you don't need?
Speaker: Like, why have we failed miserably at this when other teams have figured this out?
Speaker: If you believe other teams have figured it out, but that's a whole other separate topic.
Speaker: It seems better.
Speaker: Engineering.
Speaker: Engineering would be like the only other team that I'm thinking of where I'm like, we're like in our terms, we call it the web team.
Speaker: Like they are better at it than us is I think what Ben's highlighting.
Speaker: Not necessarily like all other teams.
Speaker: I think it comes back to stakeholders know what to ask the web team.
Speaker: They know I want this feature change or I want this thing to happen.
Speaker: Whereas with the data team, they come to us with very, very vague business questions.
Speaker: And because of that, it's hard to know, is this actually something that makes the roadmap?
Speaker: Does this make the sprint?
Speaker: Or is this literally a 30-second answer?
Speaker: And sometimes we turn 30-second answers into entire roadmap projects.
Speaker: And sometimes roadmap projects should have been a 30-second answer.
Speaker: And so I think it's because the stakeholders don't know what to ask of us.
Speaker: because we haven't done a good enough job of actually understanding what they're trying to do with that.
Speaker: That's to me, like 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.
Speaker: Interesting.
Speaker: I'm curious to hear Ben, like what you would say of like, why data teams suck at this?
Speaker: probably because the range of sizes of things is so huge and it's a little bit unknown.
Speaker: There's like, I'm curious about this thing and you're like, I don't know, maybe that'll take me five minutes.
Speaker: Maybe it'll take me a month.
Speaker: I don't know.
Speaker: I've never thought about it in this angle.
Speaker: I think one of the things that does somewhat of a disservice for data teams and like, Mode is a BI tool that has focused on ad hoc analysis in its inception.
Speaker: Now it is more of a just kind of BI and sort of has both sort of more formalized BI and ad hoc kind of folded together.
Speaker: But its initial work was ad hoc work.
Speaker: And I always sort of hated the term because it has this like very ephemeral, it's scratch work.
Speaker: It's this like one-off, pull me an email list type of thing.
Speaker: But it's not actually... There's like a negative... Sorry.
Speaker: There's like a negative connotation.
Speaker: Yeah.
Speaker: It's like my ad hoc work is something that's kind of throw away.
Speaker: You know?
Speaker: It's like... I have my ad hoc scratch pad and I have the thing that I'm building and the ad hoc thing is not lasting.
Speaker: And so that's how we have described this work and it seems like... But it doesn't...
Speaker: to me, it does a bad job of reflecting the value of it.
Speaker: Because some ad hoc work is, we need to do strategic analysis to figure out if we should acquire a company.
Speaker: And it's like, yeah, that's a really big decision.
Speaker: But it's all sort of folded under the same umbrella as...
Speaker: 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.
Speaker: I don't know.
Speaker: To me, it's like if that's how you describe the work that comes into a ticketing system is you have one term for all of it.
Speaker: And it's not literally the terminology, but it's like the fact that those two things are all kind of like tossed in the same bucket.
Speaker: 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.
Speaker: Like, okay, I want to be helpful, but it also could be a huge project.
Speaker: It's funny, you actually use the phrase ad hoc.
Speaker: That used to be one of our epics on JIRA up until about six months ago.
Speaker: And I was like, I'm done with this epic.
Speaker: I can't deal with this vague terminology of ad hoc.
Speaker: This is unhelpful to me, even in the planning purposes or repeating back to execs of what the data team is doing.
Speaker: This catch-all bucket is not sustainable.
Speaker: And so we actually retired that epic and we ended up calling it
Speaker: vastly different things.
Speaker: And there were like 7 different epics that came out of that.
Speaker: Because like you said, Ben, 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 going to send direct mail mailers to a bunch of customers in the near future.
Speaker: I think for me, it's understanding who in the company is asking for this, why are they asking for it?
Speaker: And then really quickly assessing
Speaker: I get their timeline, but where does it fit into the bigger picture of what our deliverables need to be for the entire company?
Speaker: And it's getting everyone to even my most junior analysts to think in that way.
Speaker: That has made it a lot easier because we can accept requests from anywhere.
Speaker: Because let's stop saying you have to fill out a form to make things too complicated on the data side.
Speaker: Let's take it from Slack.
Speaker: Let's take it from Workstream.
Speaker: Let's take it from anywhere.
Speaker: But let's really quickly figure out if it's going to be that 30-second task or if it's going to be that really long-term thing.
Speaker: And it does take us time.
Speaker: We need probably a little bit of time to figure that out.
Speaker: But what does that look like?
Speaker: Yeah.
Speaker: Actually, another thing that made me think of that is a way in which at least I think data work is generally different than engineering that might have some of this effect too.
Speaker: Yeah.
Speaker: What is it?
Speaker: Which is a lot of data projects can be done by one person.
Speaker: And so you can like DM somebody with the expectation that they can do it.
Speaker: Whereas if you're like, build me a feature,
Speaker: you sort of know you can't DM one person that they can do the whole thing.
Speaker: Every data project basically has one person to ever talk to, unless it's like an infrastructure thing or whatever.
Speaker: But if you're like a stakeholder, you basically have one.
Speaker: It's like, all right, this is the person that I talk to.
Speaker: This is my analyst or whatever.
Speaker: Whereas in engineering, there's more of a sense of like, there's an engineering team that I have to kind of go through, not this one person.
Speaker: Or even like a PM and I have to go through the PM.
Speaker: I can't just like go to the engineer.
Speaker: I will say we have tried to, and this isn't like a secret solution, but I have asked teams to stop DMing my team.
Speaker: And I'll say it, you know, in a much more nuanced kind way.
Speaker: And we will make very small shared Slack channels where it's like,
Speaker: 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.
Speaker: And it makes it so that it's like, there is a bit of that accountability.
Speaker: Like I'm not just going to ask for anything because there's five people on this Slack channel.
Speaker: It can't just be a DM, but also they feel way more comfortable to ask
Speaker: anything and everything.
Speaker: And then I'm able to quickly say like, Hey, our team actually doesn't have time for this.
Speaker: Or Hey, yes, we actually do.
Speaker: This is really interesting.
Speaker: We'd love to work on that.
Speaker: And so instead of having like the marketing team and data team are all on one Slack channel, we try to keep it very, very condensed.
Speaker: And that has allowed for a little bit of like that catch all category to feel less so of a, Hey, can you work on this behind the scenes?
Speaker: But yeah, it's tricky.
Speaker: It's definitely tricky.
Speaker: So Daniel, to dig into that, is that that's broken out by like topic or is that just organically come based off of the interactions you're having with other folks or?
Speaker: So each of our teams at Squatch are very, very small.
Speaker: So we'll have the marketing umbrella, but then within marketing, we'll have the life cycle team and there's five of them.
Speaker: And then within the marketing team, you have the marketplaces team.
Speaker: So their initiatives are Amazon focused and there's three of them or
Speaker: whatever that might look like.
Speaker: And I have a different analyst who focuses on each of those functions, not necessarily like one analyst to function, but one analyst owns that function and might own two or three other ones.
Speaker: So it means they know who their go-to person is, but they also know that
Speaker: the go-to person, it can't just be like a DM.
Speaker: 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.
Speaker: And they use Workstream in the same way where we use sort of those conversations in sort of the same way as that shared Slack channel.
Speaker: Very interesting.
Speaker: So Ben, 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.
Speaker: Danielle, I'm trying to remember what your initial point was.
Speaker: No, it's okay.
Speaker: I think it said stakeholders don't know how to ask.
Speaker: Like stakeholders don't ask the right thing.
Speaker: Yeah.
Speaker: Yeah.
Speaker: It's like a vague, I mean, I guess there's in product or in engineering, there is like a sense of here's a ticket of what I want, but in data, it's a much vaguer, help me solve this.
Speaker: That again, can be like a very narrow thing.
Speaker: And it's not sort of a stakeholder's fault.
Speaker: It's just like, that's the nature of the world because it's like, it's a research problem.
Speaker: My only counterpoint to that would be like, you know, with the,
Speaker: typical bug or like feature requests and software engineering or software development, like kind of the role of a PM is to figure out like what the real problem is or what someone actually wants.
Speaker: And so like a bug doesn't actually always mean that's what you should build.
Speaker: It just means this is like a problem somebody is experiencing and the same for like a feature request.
Speaker: And so it could result in something that looks a little bit different.
Speaker: So there are like kind of analogies there with, is it also on the,
Speaker: And not that you weren't saying this, but like, is it also on the data person to kind of PM that request?
Speaker: 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, well, we asked the exact thing that we're looking for.
Speaker: It's the like translation.
Speaker: 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 has that on the engineering side, has that whole wide scape view.
Speaker: and the big picture view.
Speaker: And so they know how to figure out what is the actual solution to that bug.
Speaker: Whereas if you're just asking one singular analyst, they might not necessarily have that view.
Speaker: So I think it's that things are lost in translation on that.
Speaker: And we don't do a great job on the data side translating.
Speaker: I really don't think we do.
Speaker: Does that get solved at very big companies?
Speaker: I actually don't know this.
Speaker: Yeah.
Speaker: It's like, say you're Airbnb or you're Facebook or whatever, and you've got a data team of hundreds.
Speaker: Do they have, in effect, PMs that aren't?
Speaker: I know there are data PMs that are like data product PMs that are thinking about dashboards to build.
Speaker: They're thinking more about what is the sort of technical surface area that we provide.
Speaker: Are there folks that essentially are closer to project managers, I guess,
Speaker: that are the front lines of interactions for the rest of the business that then sort of ship work off to other data feeds.
Speaker: Does that actually happen?
Speaker: Like I've never heard of that, but it seems like those organizations are big enough to kind of function that way.
Speaker: You would think.
Speaker: I mean, that's a terrible idea.
Speaker: I don't know.
Speaker: Yeah, I mean, I have honestly never really talked to a team that has done that.
Speaker: And I talk to teams about this stuff a lot, like this specific problem.
Speaker: I've seen job postings every once in a while for like data, scrum manager, project manager type of role.
Speaker: And some of the criteria will be managing requests and stuff like that.
Speaker: It just doesn't feel super common.
Speaker: Yeah, and the scrum manager thing seems like actually closer to what it would be.
Speaker: And I've never seen that for a data person.
Speaker: And it's probably like,
Speaker: That's getting awfully expensive to have like a dedicated person to manage your data on a board or whatever.
Speaker: But like a big enough company, it seems like maybe it's worth it, but maybe not.
Speaker: For my take, like, and I'm curious to the two of you buy this or not.
Speaker: And this is a slightly different twist of Ben, your comment, which is like when you think of maybe not like the biggest data teams in the world, but most data teams, when you're thinking of like their product slash engineering workflow, and then they're like
Speaker: support workflow, which is kind of what we're talking about.
Speaker: It's often that like same team or the same people having to manage that, right?
Speaker: Which is like a harder, I think dynamic versus in a software engineering organization.
Speaker: Normally it's a much bigger team.
Speaker: And so you've got PMs to triage support and it's not like the same team doing everything, every sprint all at once.
Speaker: And so I think that lessens the burden and maybe it adds a little bit more
Speaker: opportunity for organization, but I don't know if you think that's right or wrong.
Speaker: I don't know.
Speaker: There's like a totally different direction you could go in this to me too, which is in some ways of just like embracing the chaos.
Speaker: Like there's a version of this where it's like, all right, how do we have sort of everything super organized?
Speaker: And I think if that's what you think is right, yeah, that probably makes sense.
Speaker: But sort of the further we go down that path of like, oh, we got to have this structure in this process and this process and this process.
Speaker: There's part of me that sort of was like, well, maybe we just actually like the free for all isn't so bad.
Speaker: And we just figure out a way to like make the free for all work a little bit better if the alternative is.
Speaker: some super over-engineered process for making this work, especially if the team is usually between five and 10 people or whatever.
Speaker: 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.
Speaker: We feel like we can ask you anything.
Speaker: And I feel like if you try to fix too much of the chaos, you lose that approachability.
Speaker: I almost want to, I think Ben, you highlighted at the end, like there's the sharing back out at the end of the part.
Speaker: I think it's almost more important of like, 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?
Speaker: Well, the intake is like the biggest burden on us and we need to figure out how to handle it as a team.
Speaker: I don't think it's, there's a silver bullet for how to like tell the rest of the stakeholders how to do it all.
Speaker: That's my opinion.
Speaker: Yeah, and they worked on a data team prior to Mode that actually handled this reasonably well in kind of a dumb way where we essentially, the team was big enough to do this.
Speaker: It was probably 10 analysts, data scientists.
Speaker: But basically we did something sort of like that where it was one, there was one person who just like, all the questions came in through one, what amount to a Slack channel.
Speaker: There was one person whose job it was just, that was your week.
Speaker: Like 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.
Speaker: you affect where like this kind of scrum master type of thing.
Speaker: And the other consequence of that was there was only one person who was like sort of actually staffed on working on this stuff, which meant, yeah, they could kind of escalate things that they needed to.
Speaker: But for the most part, we just didn't do that much of that kind of work and gave ourselves, you know, the valuable work is the stuff we're going to sort of assign in clear ways.
Speaker: The stuff is, if it bubbles up, we'll do it.
Speaker: But it was a little bit more of like an acknowledgement that this type of
Speaker: intake work is usually lower value anyway, so we're just not going to give it that much time.
Speaker: Did you have like the same person who did that at all times?
Speaker: Or was it like a role that rotated?
Speaker: It was every week or every two weeks.
Speaker: And typically it was actually
Speaker: It was like the job of usually the more junior person to do.
Speaker: So we were like hiring reasonably quickly, probably hired a person once every two months.
Speaker: 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.
Speaker: And then you'd kind of enter the rotation area.
Speaker: else.
Speaker: It was good exposure for onboarding because you'd get asked questions across the business.
Speaker: You'd have to meet a bunch of people in the process.
Speaker: The questions usually weren't make or break questions.
Speaker: 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 mess something up.
Speaker: So it was sort of high visibility, low risk in a lot of ways, types of things.
Speaker: And that actually worked pretty well, like I said.
Speaker: Yeah.
Speaker: We had no documentation of it whatsoever.
Speaker: Once we answered the things, it was gone.
Speaker: But in terms of intake, it actually worked really well.
Speaker: Yeah, kind of like a help desk, but for the data side of things.
Speaker: Yeah, no, that makes a lot of sense.
Speaker: I think what I would say are Dr. Squatch stakeholders are fairly...
Speaker: good at using whatever tools they have available to answer their easy questions.
Speaker: And 80% of the time, their questions lead to awesome long-term projects.
Speaker: And so that's where it's like, if it's just treated as a help desk, we often lose like, oh my gosh, this was something that we really could have built an entire thing on.
Speaker: That would have like revolutionized things.
Speaker: But I love the help desk idea.
Speaker: And I actually wonder if it would be or not even 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.
Speaker: I love that.
Speaker: That's cool.
Speaker: You know, often when you talk with data folks about like this part of their workflow and like managing requests, it's one of the things that they find like really annoying or it's a not appreciated part of their job.
Speaker: And so the question was like, do you think that's like a symptom or like a cause here, right?
Speaker: Or do you disagree with that statement completely?
Speaker: It's not something people seem to want to do.
Speaker: It's not like high on the list of if they wrote their job description, they would not put this on their job description in most cases, I would say.
Speaker: It sort of feels like most people treat it as a necessary evil.
Speaker: Though actually, I've never thought of it this way, but actually I think you may be on to something a little bit of it's partly because it's poorly managed, not because the work itself is bad.
Speaker: Like in a lot of cases, the work itself is actually going to be kind of fun because you like bounce around from project to project.
Speaker: You have like, you're learning different things, trying new stuff.
Speaker: You don't actually have to stick on something for forever.
Speaker: You don't get buried in these like frustrating, never ending loops.
Speaker: you have like, it's fairly impactful in that someone asks a question, you can see the immediate result.
Speaker: Like sometimes it's like silly questions you don't want to deal with.
Speaker: But like, if you get enough questions, you can find the ones that are useful.
Speaker: There's something about it that feels very kind of low man on the totem pole.
Speaker: You're just, yeah, answering tickets.
Speaker: Like you're like a ticket fan.
Speaker: Yeah, I was when you were talking about like, oh, we throw like the most junior person at this, right?
Speaker: I'm like, oh, maybe there's, you know, 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's often it makes you think I'm like, what am I just a support agent at an airline, you know, or like the annoying IT guy who comes and bitches at me while I try to fix my computer type of thing.
Speaker: which is not, I think, what most people think of or want when they embark upon their data career.
Speaker: Yeah, and then 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.
Speaker: 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 is hard.
Speaker: And that just takes context, it takes some experience.
Speaker: if you're put on a cue, it's more proactive than people think because there's not just like answer question as it's asked, as Danielle pointed out, like people don't really ask questions in quite the right way or they don't know what to ask.
Speaker: And like, there is a lot of back and forth there, but you're not quite as like generative in the sense that you do have like a big list of things to do and you can just kind of follow those things.
Speaker: So that was one of the other reasons why it worked relatively well for junior folks.
Speaker: But I think, I don't know, it does seem like it is maybe actually good work that is,
Speaker: we treat badly, partly based on the things that I've said.
Speaker: It doesn't get a lot of respect.
Speaker: Well, that's where I just, I wonder is like, is that part of the problem, not the result of the problem?
Speaker: Is it just, we just, because of all of these reasons, the social signaling, the last person on the totem pole, the, it's just annoying to be interrupted 20 times a day with like the one-off question, do kind of intentionally do a bad job in this area?
Speaker: or even subconsciously, right?
Speaker: And it leads to broader problems kind of around how you interact with the organization.
Speaker: I feel like I love that statement just because... Or I love this thought process because I almost feel like it goes back to what we value as data.
Speaker: I mean, I'm talking for myself here, but I'm grouping all of us together.
Speaker: What do I see as success?
Speaker: I'm like, ooh, I get an entire day to write Python and no one bothers me.
Speaker: That is a successful day.
Speaker: But that actually does nothing for the company.
Speaker: What does things for the company?
Speaker: It's like...
Speaker: answering insights.
Speaker: It's like caring about the way that these other teams think.
Speaker: It's like giving quick answers here and there.
Speaker: And so I think it's the fact that like this particular, like these kinds of intake requests, they come with urgency.
Speaker: They need you to be available.
Speaker: They need you to respond.
Speaker: And so it does get that bad rap.
Speaker: But if you can sort of shift your thinking or make sure that you're not always doing that, maybe it's not like 100% of the time, like Ben said, like having rotation to do it, it does become really rewarding work and it's awesome.
Speaker: 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 online.
Speaker: And to always feel like what they're asking for is the biggest thing on your to-do list.
Speaker: 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.
Speaker: But it also needs to be the type of thing where we're not all doing it 100% of the time, for sure.
Speaker: Yeah, and that actually, there's another point of that too, I think is a good point about you have to work with other people.
Speaker: And it's not that people don't, that's not seen as like lower level work.
Speaker: But I do think there is some groups of folks that see like the data work is I want to have a clear calendar and like,
Speaker: headphones on to just sit down and like do analysis and like build stuff and like somewhat of an engineering mentality of like I need to be in a flow kind of thing and if I have to have these meetings or conversations or share stuff like that that's the peripheral work around the core work that I'm doing and not sort of seeing that as like that's the job exactly and that may be like a demeanor thing it may be a branding thing but I do think there's like a no part of the job is all this stuff and if you celebrate that then then you actually solve some of these problems too
Speaker: And if you're good about not letting it get in the way, like it's okay to not feel like you need to respond to that DM in 30 seconds.
Speaker: Like you should be responding within, you know, 10 minutes, but it doesn't need to be within 30 seconds.
Speaker: Cause I think the things that we're working on are intense things.
Speaker: we're thinking a lot.
Speaker: We are really thinking about whatever thing we're solving at that moment.
Speaker: 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.
Speaker: So being really conscientious about when you're going to be answering questions and when you're going to be thinking about maybe bigger projects that you're working on is really helpful too.
Speaker: Yeah, I mean, I think for this specific problem or in general, how do you manage deep work time versus like interrupt driven collaborative time is a big part of the problem.
Speaker: And I know 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.
Speaker: And there's the like deep work engineering hat where like you have to be heads down focused for some like a long period of time to solve a problem.
Speaker: And then there's like these other aspects of like product work and prioritization and scoping and asking the right questions on top of like interrupt driven, almost like support type of work.
Speaker: Right.
Speaker: And it's very few other teams at a company where like the same team or the same person on the team is like constantly having to switch between those different modes.
Speaker: No pun intended.
Speaker: Yeah, and I think that's one of the reasons, too, that the sort of rotational thing worked reasonably well was because while you had to switch in out of those modes over the course of weeks, but it was typically not within the same day or hour where it's like, oh, I have to keep my eye on some imbalance set of things.
Speaker: I've got to respond to these messages.
Speaker: It's like, no, you had the project you were working on.
Speaker: And if you were on the queue, you didn't have a project that week.
Speaker: Like you weren't expected to do anything.
Speaker: And we effectively ran it like sprints.
Speaker: It wasn't officially that, but effectively we ran things.
Speaker: And if you were, you know, that was your week to do that, there was no expectation of you really to get much else done.
Speaker: It was like, oh, if you have time, fine, here's the thing.
Speaker: But like, we're not going to care if you don't do that this week.
Speaker: Like your job is to monitor the queue.
Speaker: It's almost like if we could find the sweet spot between having that queue, but also changing the mindset of like the approach to those asks.
Speaker: I feel like those two things combined.
Speaker: are kind of where it lies.
Speaker: Because I do think we need that shift in mindset of this isn't the worst thing that you can do.
Speaker: This is actually something that enables others to do their job better, which is the whole purpose of data.
Speaker: Yeah, I mean, Daniel, to that point, you know, you talked about like really interesting projects or things coming out of these like requests.
Speaker: Does that get like highlighted for your team?
Speaker: Do you incorporate kind of that type of opportunity into, I don't know, mission for your team or how you talk to folks about kind of success and growth and all that stuff?
Speaker: Yeah.
Speaker: Do you mean externally, like with our stakeholders or just with the team itself?
Speaker: I was thinking more like internally within your team, maybe trying to get like folks riled up and excited about like answering people's questions, but it could be, you know, with stakeholders too.
Speaker: Yeah.
Speaker: How do we get them kind of excited?
Speaker: I think one, it becomes super relational.
Speaker: They have relationships with these stakeholders.
Speaker: It's not just transactional, maybe is like the way that I would phrase it.
Speaker: It's not just like they ask for things.
Speaker: I like to make sure that they know my team knows.
Speaker: They can also ask the stakeholder for things.
Speaker: They can be like, Hey,
Speaker: I'm noticing this.
Speaker: Can we do a project on this particular topic?
Speaker: It would be really fun and interesting for us.
Speaker: And we think that it has high opportunity.
Speaker: And so it's creating sort of that relationship.
Speaker: And then I think it is leading by example.
Speaker: So 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.
Speaker: And my team is easy.
Speaker: They are all very, very, uh,
Speaker: interrelational with a lot of the other people on the Dr. Squatch team, which makes it so simple to kind of have those.
Speaker: And then it is that like change in mindset of not just when you're asked to do something, do that something.
Speaker: It's when you're asked to do something, ask why you're doing it.
Speaker: and then figure out if the solution is the best solution or if there's something more that we could do beyond that.
Speaker: 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.
Speaker: You get a quick and easy project or you get something that might be long term.
Speaker: So it's that pushing for why is the stakeholder asking for this and why is this important to them?
Speaker: Very cool.
Speaker: Well, I think with that, that might be a good place to potentially wrap up.
Speaker: We've been going for a little while.
Speaker: Ben, Danielle, I don't know if either of you have any other parting thoughts on this topic before we wrap?
Speaker: No, this is fun.
Speaker: None for me.
Speaker: Awesome.
Speaker: Well, thanks again for you both for joining me and
Speaker: Thanks for listening, everyone.
Speaker: And hopefully we will see you next time on our next installment of the Knowledge Pioneers, where again, we're exploring how teams create shared consciousness around your data.
Speaker: Thanks, Nick.
Speaker: Thanks, Nick.
Speaker: Thanks again, everyone.
