Today I’m chatting with Emilie Shario, a Data Strategist in Residence at Amplify Partners. Emilie thinks data teams should operate like product teams. But what led her to that conclusion, and how has she put the idea into practice? Emilie answers those questions and more, delving into what kind of pushback and hiccups someone can expect when switching from being data-driven to product-driven and sharing advice for data scientists and analytics leaders.

Highlights / Skip to:

• Answering the question “whose job is it” (5:18)
• Understanding and solving problems instead of just building features people ask for (9:05)
• Emilie explains what Amplify Partners is and talks about her work experience and how it fuels her perspectives on data teams (11:04)
• Emilie and I talk about the definition of data product (13:00)
• Emilie talks about her approach to building and training a data team (14:40)
• We talk about UX designers and how they fit into Emilie’s data teams (18:40)
• Emilie talks about the book and blog “Storytelling with Data” (21:00)
• We discuss the push back you can expect when trying to switch a team from being data driven to being product driven (23:18)
• What hiccups can people expect when switching to a product driven model (30:36)
• Emilie’s advice for data scientists and and analyst leaders (35:50)
• Emilie explains what Locally Optimistic is (37:34)

Quotes from Today’s Episode

• “Our thesis is…we need to understand the problems we’re solving before we start building solutions, instead of just building the things people are asking for.” — Emilie (2:23)
• “I’ve seen this approach of flipping the ask on its head—understanding the problem you’re trying to solve—work and be more successful at helping drive impact instead of just letting your data team fall into this widget builder service trap.” — Emilie (4:43)
• “If your answer to any problem to me is, ‘That’s not my job,’ then I don’t want you working for me because that’s not what we’re here for. Your job is whatever the problem in front of you that needs to be solved.” — Emilie (7:14)
• “I don’t care if you have all of the data in the world and the most talented machine learning engineers and you’ve got the ability to do the coolest new algorithm fancy thing. If it doesn’t drive business impact, it doesn’t matter.” — Emilie (7:52)
• “Data is not just a thing that anyone can do. It’s not just about throwing numbers in a spreadsheet anymore. It’s about driving business impact. But part of how we drive business impact with data is making it accessible. And accessible isn’t just giving people the numbers, it’s also communicating with it effectively, and UX is a huge piece of how we do that.” — Emilie (19:57)
• “There are no null choices in design. Someone is deciding what some other human—a customer, a client, an internal stakeholder—is going to use, whether it’s a React app, or a Power BI dashboard, or a spreadsheet dump, or whatever it is, right? There will be an experience that is created, whether it is intentionally created or not.” — Brian (20:28)
• “People will think design is just putting in colors that match together, like, or spinning the color wheel and seeing what lands. You know, there’s so much more to it. And it is an expertise; it is a domain that you have to develop.” — Emilie (34:58)

Resources and Links:

• Blog post by Rifat Majumder
• storytellingwithdata.com
• Experiencing Data Episode 28 with Cole Nussbaumer Knaflic
• locallyoptimistic.com
• Twitter: @emilieschario

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. And today I have Emilie Schario on the line who is a Data Strategist in Residence at Amplify Partners. Welcome.

Emilie: Thank you. Thank you so much, Brian, for having me. I’m really happy to be here today.

Brian: Yeah. You want leaders to run their data teams like product teams.

Emilie: I do. I do.

Brian: What’s that about? Tell me about that.

Emilie: I have spent the bulk of my career working in SaaS, and mostly in the dev tool space, and I’ve gotten the chance to work with really phenomenal product leaders along the way. I really formed the bulk of my thinking here in my time when I was at GitLab, with my colleague Taylor Murphy. And together, we gave a talk and we wrote this blog post on what it means to run your data team like a product team. And if I had to give you the one-sentence takeaway, it’s understanding the problem you’re trying to solve instead of building the features you were asked for. And we saw product leaders and product managers do this over and over and over, where a customer would ask for, “Can I have a blue button that does this thing?”

And the product manager would actually try to understand, like, “What are you trying to do?” Maybe we’ll build the blue button, but maybe we’ll build something else. But data teams get stuck in this, like, intake trap where people don’t come to data teams and say, “We’re trying to improve retention,” or, “We’re trying to understand conversion.” They say, “Can I have a dashboard that has these numbers on the bottom, and it’s, like, aggregated monthly and the charts are blue and yellow.” And data teams just go build that. And so, the idea that we—our thesis that we presented is, we need to understand the problems we’re solving before we start building solutions, instead of just building the things people are asking for.

Brian: Sure. I think one of the places this goes wrong is, “Well, Emilie, they just said the problem is they don’t have a dashboard that has a blue button on it. That’s the problem.” So unpack—

Emilie: Is it?

Brian: That for me. [laugh].

Emilie: Yeah, I would ask the question like, is it really? Because one of the things I’ve seen over and over is they ask for a dashboard, they get it, and then they realize like, that actually didn’t solve what they needed, right? They come back and they’re like, “Oh, yeah, that’s what I asked for, but I needed to be able to slice and dice it by this parameter,” or, “Yeah, but this didn’t give me the insights that I was looking for. I couldn’t find the takeaway that I needed.” And so, I think in a lot of ways, those sorts of asks of, “I need the blue button,” or, “I need this dashboard built,” are really just people jumping at solutions without necessarily knowing the problem they’re trying to solve.

And I can’t blame them. Like, a lot of times these asks are coming from people outside of the data org and they don’t know what they don’t know, right? They don’t know how to ask a great question with data, or they don’t even know what data is available, they don’t know how to approach the problem, they don’t know what you could help them with. So, they’re asking for something that seems feasible in their mind. And if we could flip that on their head and try to understand the problem that they’re trying to solve, which might be, “We’re rolling out a pricing change and we need to talk to all of our customers that are on the old pricing plans.”

Well, that’s a problem where the data person can say, “Here’s how we solve it for you. Here’s how we get that information,” instead of, “I need a dashboard with everyone who signed up before January 1st.” Those are our two different ways of asking for what might be the same information, but also might fundamentally be a different problem. And I’ve seen this approach of flipping the ask on its head—understanding the problem you’re trying to solve—work and be more successful at helping drive impact instead of just letting your data team fall into this, like, widget builder service trap.

Brian: Yeah but isn’t it the business’s job to know what they want? Like I’m so sick of, like, you know, they don’t know what requirements and then we give them what they asked for, and then they don’t use it. Play this out for me: whose job is it to go and surface especially these unarticulated needs that are not in the Jira ticket or they’re not in the 52-page product—

Emilie: [laugh].

Brian: —requirement document or whatever the artifact is. I think a lot of analytics and data scien—is like, “That’s not what I’m here for. I know Python. I know crazy modeling, I know NLP, I know how to build a machine learning pipeline. It’s not my job to also figure out why they need it.” So, unpack that. Like, whose job is it, and where does that fall, like, that conversation?

Emilie: I have a slightly different mindset around hiring than I think some people. Like, I grew up inside of a Dunkin Donuts. And what I mean by that is, my mom’s been working at Dunkin Donuts for the last 20 years. So, my first interactions with, like, math and addition and subtraction were from counting change and trying to figure out how to do cash change faster than the register could tell me what the change for your ten-dollar bill was. And I have this memory—and it’s not just a one-time thing; it was something that happened over and over—where we’re walking across the dining room and there’s a straw wrapper on the floor, someone had, you know, just taken the paper and thrown it.

And my mom picks it up and she puts it in her pocket. And every hour, someone’s job was to go through the dining room and make sure there were no napkins or straw wrappers on the floor. So like, the straw wrapper would have gotten cleaned up eventually by someone was looking to solve exactly that problem, and my mom could have walked right by it; lots of people had. But she didn’t. She saw the problem and she fixed it.

And she didn’t fix it with, like, the perfect solution. It’s not like she picked up the straw wrapper and she took it over to the trash cans, she put it in the trashcan. She put it in her pocket. She made the problem of there’s a straw wrapper dirtying the dining room better. And not once along the way did she ever say something like, “It’s not my job.”

And so, when I hire, I look for what I call a floor-sweeper tendency, right? Like, if you see a straw wrapper on the floor, pick it up and put it in your pocket. Or if you see that the trash is full, take it out. Or if you see that the printer is low on ink, figure out how to get another ink cartridge. But if your answer to any problem to me is, “That’s not my job,” though I don’t want you working for me because that’s not what we’re here for.

Your job is whatever the problem in front of you that needs to be solved, needs to get solved. And I think this idea of, like, “These are my boundaries, these are the specifics of the role in which I operate,” like, the answer of who scopes out the requirement is the person who’s trying to drive business impact with data. And so, as data professionals, we need to take ownership over—what’s the phrase? “Data dies in darkness.” Like I don’t care if you have all of the data in the world and the most talented machine learning engineers and you’ve got the ability to do the coolest new algorithm fancy thing. If it doesn’t drive business impact, it doesn’t matter. So, we have to make sure we’re focusing all of our discussions around how we enable people to drive business impact with data first, and then everything else comes second.

Brian: Yeah, I completely agree with you. And I think it’s a—to me, it’s a dance, and it’s a dance which necessitates—well, not all dancing requires two or more people, but the idea of it’s something we’re doing with the customer, and/or stakeholder, and/or user, or maybe all of them, it’s not something we’re doing for them. So, inherently it’s a two-way exchange; it’s a two-way conversation. Minimally two ways. It’s not a one-way, “Here’s what I need, let me know when it’s done,” kind of thing.

That doesn’t work. I think I agree. It leads to outputs, not outcomes. And what people really want are outcomes, even when they asked for outputs. So, a lot of it is in the decoding of what’s behind the request for the blue button.

Why does it need to be blue? Why does it need to be on a dashboard? Why a dashboard at all? Like, unpacking these kinds of tactics that sound like goals and objectives, and they’re not; they’re tactics. And we need to unpack those things in order to really get what people want so that we can deliver something that’s going to delight and hopefully get used and all of that.

Emilie: Absolutely. There’s this great blog post by Adam Stone of—he’s an analytics engineering at Netlify on Locally Optimistic on data-business partnerships, and how—we can look at HR orgs as a parallel because if you look at large companies, you have HR business partners who report into the HR organization, but almost always have, like, a functional business unit that they work very closely with. And so, they might report into HR but be focused on sales, or they’re reporting into HR, but pretty focus on the product team and the design org. And what Adam says is—and I agree with—is we actually need to form those sorts of partnerships with the other parts of the organization. And so, the data person who is working closely with the marketing team, or working closely with the team releasing the whatever new feature, it’s not enough to just see yourself as the data person supporting that initiative or that campaign, you need to have ownership and accountability as part of it. You are part of the team that’s executing on that release. And so, I think that sort of framing can help drive the accountability piece that a lot of data people feel when they’re so used to just like, “Okay, I built the thing you want it, I’m going to throw it over the wall now hope it sticks.”

Brian: I want to get into more about that, but first, tell us what Amplify Partners is, and what is the Data Strategist in Residence, just to give people a little bit of background about who you are and what you.

Emilie: Yeah, thank you. So, Amplify Partners is a seed-stage venture capital firm, focused on data tools, Dev Tools, cloud infrastructure, and we invest in technical founders. I joined Amplify about a year ago. Prior to that I was head of data at Netlify. Before that, I was the first data person at GitLab, joined us employee number, like, 280, watched the company grow to over 1300 people in two-and-a-half years. Spent a year in a BizOps-style role as Interim Chief of Staff to the CEO.

And so, I’ve been in data roles, but I’ve also been in roles where data was a tool in my toolkit to get things done. And then I’ve also led data organizations. So, I use these three perspectives to shape how I think about building effective data teams and data-driven companies. At Amplify, I work with our portfolio companies of a variety of stages and in different domains, helping them take these things that I’ve done in my previous life and at Netlify, and help them learn from my mistakes: some of the hiring mistakes I’ve made, some of the how do we organize data teams mistakes that I’ve made, hopefully, they don’t need to repeat because we can work together to overcome some of those.

Brian: Sure, sure. So, it sounds like industry is primarily technical software, is that correct?

Emilie: Mm-hm.

Brian: So, that’s most of your perspective that we’re talking about today is coming from the land of a software company that has a data team, or is building out a data team or something along those lines to inform the business?

Emilie: Exactly. I have worked mostly in software companies. I prefer B2B SaaS, generally. But I’ve also worked in direct-to-consumer.

Brian: Do you have a definition you like of what a data product is?

Emilie: It’s interesting because the more I’ve talked to people about this, the less confident I feel that this is, like, a thing that can be defined across the board. Because I think the answer is a little bit, like, “It depends.”

Brian: Yeah.

Emilie: And a lot of, like, I know it when I see it, right? I think the Excel spreadsheet that the [FPNA 00:13:20] person maintains, where he runs a SQL query and then copies the results and puts it in that spreadsheet every week, I would say that’s a data product. Has nothing to do with the data warehouse, nothing to do with the data team, but it’s still part of the organization’s data consumption. And so, I don’t have a definition I love as much as being able to say I know it when I see it.

Brian: Am I correct that because you’re working with seed-stage companies, you’re able to hire in the mentality and skill set that you need to accompany someone that is an analyst or analytics professional or a data science professional? By default, you’re hiring and someone that has this kind of problem or customer-centered mindset as well as the technical chops? Is that a safe assumption or is it more like no, we get them in with the tech chops, and then we run them through our training and we try to, like, get them on board with the way we want them to think about this? Like, is it training? Is it hiring? Is it both?

Because this is not—at least in my experience, this is not a default state that many data professionals have. This is a learned behavior, or there’s someone that came out of a product world and maybe went into the data world or something, but it’s not very inherent and natural to find in the wild.

Emilie: The companies in our portfolio that I work with tend to be of all stages. So, Amplify is a seed-stage firm, but that means we’re going to keep up with you as you grow. By the time you’re building out your data org, you might actually be a Series B or a Series C company. What we’re looking, if we’re working together in, like, “Okay, we’re ready to build a data team; we’ve identified these problems in the org; we think that’s the solution. How do we go about doing that?” I tend to think that the softer skills like the analytical interest, and asking good questions, and perseverance, when things are hard, like, those things are harder to find in people, and I can’t teach you those over the course of a 90-day onboarding session.

I can teach anyone SQL. And so, when we hire the first person, obviously, usually you try to hire more senior candidates, someone who’s going to be able to thrive in a solo environment and all that kind of stuff, but what I’m really looking for, first and foremost, is that floor-sweeper quality that I mentioned earlier. Like, are you the person who’s going to see a problem and trying to figure out how to make things better? And then after you’ve checked that box, we can look for has the right SQL or has the right technical skill set or can understand these problems. But it’s almost like that’s the prerequisite.

And then, as a team grows, what I’m looking for is generally filling out the right gaps on the team. So, if you have two analytics engineers who come from very similar backgrounds and I’m hiring a third, I going purposefully go out and adjust what criteria are important to me to build out a slightly more well-rounded team. So, a lot of it—as with all good questions—a lot of the answers are really, it depends.

Brian: Sure. But I think the interesting thing is, it sounds like your first screening criteria is actually in what we could call the soft skills space of this problem understanding, or having some type of empathy [laugh] for the situation. And not just, like, “I am a tool whacker, and I will whack this thing with Python if you tell me to.” And that sounds like I’m taking I don’t mean that all people in data professions and technical work are that, but there is, especially as companies get larger, you tend to find more and more people that identify with the tool that they work on, and that’s their identity. It’s really wrapped up in a tool set or a toolchain or the coding skills they have or whatever it may be. And I think that’s hard, it’s hard stuff to change. So, it’s nice if you can pre-screen for different qualities.

Emilie: Absolutely. And I see it especially in earlier career people too, is that they will struggle more without that, like, hard list of requirements. And so, when companies reach a certain size, I think we see them hire sometimes product managers, for the data team. There’s a great blog post by Rifat Majumder on data PMs specifically that I like to point people to.

But once you reach, like, a critical size, where it makes sense to bring that role on, I think—and it’s not mandatory, but it is a useful prerequisite for bringing on more junior and intermediate earlier stage career folks so that you can give them a little bit more support in that requirements-gathering and understanding what the problem they’re trying to solve is and how that translates into whatever it is they need to build.

Brian: I know you’re a fan of the Jobs-To-Be-Done Framework, which is very common in the user experience space. Talk to me a little bit about where UX and design kind of fall into this. How do these teams engage that you’re constructing? Do they have designers on staff? Do you try to find people that know a little bit about UX and then they handle that? Like, tell me about all that, how that works.

Emilie: I would love to get to a world someday where I had, like, a data designer or data UX person who could help kind of shape and teach a lot of those principles. So, much of it today is just, like, “I think this information should be presented in a bar chart, so let’s present it in a bar chart.” Or, “When I click the toggle from the line chart to bar, it seemed to make more sense.” But data is really a means of communication, so we should be super intentional. Like a line chart and a bar chart communicate fundamentally different things about whether those different data points are related to each other.

I have not had the chance of having a data UX designer or a UX designer on any of my data teams, but I do think it’s the way, as data becomes more important, we’re going to see more and more of it. And there’s this great—not great; this very actually quite sad stat that most big data investments are considered failures. That’s from [HBR 00:19:52]. And I think part of it is because we’re realizing that, like, data is not just a thing that anyone can do. It’s not just about, like, throwing numbers in a spreadsheet anymore. It’s about driving business impact. But part of how we drive business impact with data is making it accessible. And accessible isn’t just giving people the numbers, it’s also communicating with it effectively. And UX is a huge piece of how we do that.

Brian: The way I always explained this to non-designers, like, in my training when I teach designing human-centered data products is this idea that there are no null choices in design. Someone is deciding what some other human—a customer, a client, an internal stakeholder—is going to use, whether it’s a React app, or a Power BI dashboard, or a spreadsheet dump, or whatever it is, right? There will be an experience that is created, whether it is intentionally created or not. Who owns that? Like, is there deliberate thought put into that? Does a single person own that? Like, how does that happen if there isn’t, like, a titled designer working on it, so to speak?

Emilie: I like to suggest the Storytelling with Data book by Cole Nussbaumer Knaflic. She worked in HR analytics at Google and then has now done a number of things around helping data communicate. And I think that is almost the first line of defense. It’s the baseline of knowledge that I want my team members to have. And recognizing that people who are less internal customer-facing, they’re going to need less of this knowledge, but being able to give my team as many resources as I can around, like, here is the best way to do it, even if it’s not your expertise is a really great way.

The blog storytellingwithdata.com is also great. And there used to be these, like, monthly challenges—I don’t know if that’s still true—but they’re great ways of seeing how multiple people will approach the same problem, the same communications challenge with similar-ish datasets. I think that’s always a great reference of there are multiple ways to approach any problem. There is no one right answer. We could address this in many ways. What are some of the approaches we could take? And seeing other people do that with data is a great way to help inspire whatever problem we’re trying to apply our skill set to.

Brian: And just for listeners who are new to this show, episode 28, I actually did talk to Cole on the show. The [laugh] one of the funny things I remember from that interview is that she doesn’t personally identify with the title of a designer, and I was kind of like—I mean, I’m not the one to knight people [laugh] as a designer, but it’s like, you’re very much walking like—it’s when you walk the talk, talk the talk, you’re doing all the practical things about what designers do, specific in this data kind of space, so I think she is in every essence of what that word means, she is a designer. And you know, she’s running a business as well, but she has that mindset there. So, I agree that she’s a great resource for DataVis and data storytelling stuff, so I’ll totally second that. One of the things you said in your article, at locallyoptimistic.com—is that correct? That’s the—

Emilie: Yes.

Brian: —where you guys published a lot of your thinking—when moving your data team to the product model, you should expect some pushback from other people in the organization. Who’s going to push back what are they not going to like?

Emilie: The people who are very used to your data team functioning as widget-builders. And I’m not trying—I’m going to put this caveat out there; I’m not trying to call any of my former colleagues out here. But with that caveat, if your head of finance is used to a world in which they had a data analyst—or whomever they worked with—who they were very used to saying, “Please build me this chart that had months on the bottom and bar charts like this, and it did this, this, and this.” And now you’re going to get pushback of, “Yeah, but what’s the problem you’re trying to solve with this dashboard?” They’re just going to see it as friction, and so part of what you’re going to have to learn as you’re doing this, as you’re implementing this model is, when do I do it, when do I ask the questions, when do I push back against the ask, and when do I just build the widget?

And that is a place that a Data PM can definitely help solve understanding the nuances of the org, but it’s also just a place where a data manager really makes a difference. Because that’s a people problem first and a technical implementation problem second. The technical problems in a lot of ways are much easier than the people problems. So, that’s where the people who are so used to having their asks just built the way they ask them to, that’s where your pushback is going to come from. But what I found is actually, there’s that initial pushback, and then once you’re rocking and rolling in this way, there’s a lot more space to operate.

So, one of the things that we started doing at Netlify, was we flipped these asks on their head, and then we started doing what I call proactive insight discovery. So, the data team would carve out time to not do things that other people were asking for, we were not solving other people’s problems; instead, we were floating in the data to try to find interesting things. And it would start small, but we started up this internal blog, we started pushing these insights out. White pens lead to better handwriting than blue pens, or people who are wearing red shirts are more likely to buy on Thursdays than on Friday.

So, we would find these things in the data and we would push them onto this blog. And eventually, I was sitting down with, actually, our VP of product, and he said to me, like, this is my homepage. I check this internal blog multiple times a day because suddenly, instead of just hearing about the things that were popping into his head and he was asking questions for—and he was passionate enough to, like, submit well-structured requests for information for—he was having information pushed to him. And that was much more impactful, not just to the business, but to the whole company because he had the information he needed, but also we were communicating that to everyone in the company as opposed to when the head of finance made that ask for that dashboard to have this widget, the head of finance was benefiting. If we could push information out to the whole company, product would see that, maybe they’d adjust the plans for the next sprint appropriately, marketing could keep that in mind, and finance could have a sense of what was driving everything. So, at first, you get this pushback, but what I found is, over time, you actually end up buying yourself more space where the org will let you operate successfully.

Brian: I would agree with that to a point, and I would say, I think the more the data team really understands the world of this case, what it’s like to be the VP of product, and what kinds of things you’ve asked for in the past such that the insights that you’re generating on your own, which you don’t know if they’re necessarily going to be useful, they have a little bit better chance of being useful because you know something about that world. Otherwise, I feel like you’re taking a chance that you’re just gen—you could become a noise generator as well. But more importantly, the business really wants to make—not enough data is rarely the problem; it’s just that there’s an—or I should say, a lot of metrics are coming at people; there’s not always a lot of signal in there. So, part of it’s like where’s the useful signal, right? And I feel like if teams are doing a good job with the giving people what they asked for, unpacking that into what the real need is, and then delivering on that stuff, it’s easier, I would ima—and maybe you tell me I’m wrong, it’d be easier to get them to listen to questions they did not ask for, but now this data team is doing innovation work, they’re coming up with new things that have not been asked because no one even knows to ask the questions at this point.

So, we’re generating some answers here which might lead to interesting questions; they’re more likely to be receptive to that if they know you can actually deliver on when I do have a very practical need, I know that you can also deliver on that. I think it just changes the trust and the understanding, and kind of like, “Yeah, we’re going to give them a little leash here. Go playground; go have your sandbox; do some of that stuff, that magic math, whatever that analysis stuff that you guys do that I don’t get, I’m more interested in hearing about that now because I know you’ll hit it out of the park when I need you to.”

Emilie: I think that’s where we really have to have this operating model of a partnership instead of order-takers, or service teams, or however people want to approach it, where we really have to understand the problems for our customers. And in our case, our customers are internal and may be that VP of product. But this is why I like the framework that Adams laid out so much is that it really is about that relationship-building first and how understanding that customer empathy really changes how and what we can build together.

Brian: What are some of the hiccups on this path that companies are going to have when they try to—if they decide to try to adopt this? Like, it sounds like you’re saying that the promise of doing things this way with this kind of product approach is that we’re actually going to solve some real needs, the solutions are actually going to get used, therefore the team will also have a better impact, so [laugh] happier staff and the leader is going to feel better about the value they’re creating. Am I correct about what the kind of promise is if one was—

Emilie: Yes.

Brian: —to do it this way?

Emilie: The happy path; that’s it.

Brian: Where’s it going to go wrong? Like, are there any things, like, you know, we can teach to the listeners about, like, “Okay, like, that sounds good, but you know, what do I got to watch out for? What can you teach me that I don’t need to relearn the hard way that you’ve already done?”

Emilie: What goes wrong is that there are 20 years of people who have worked in job titles with data in them, and they are used to operating in an IT model, where the data team gets a ticket and they send someone a CSV. And it’s not wrong; it was the model that they operated in. It was fine. It was just, if that’s someone’s mental model and your mental model is different and you use the same word to refer to both of them, you call them both data organizations, well, someone risks not speaking the same language as their coworker. I don’t know the solution to that problem other than working really hard with people to clarify what they mean by their language and aligning on expectations.

Like 80% of the world’s problems, I’m convinced are just expectation mismanagement.

Brian: Give me an example of that.

Emilie: I love to use the one around customer. So, someone says, “How many customers do we have?” Do you mean accounts, teams, customers, users? Like, I work in B2B staff, right, so—

Brian: What’s a customer? [laugh].

Emilie: What’s a customer? It could be an individual, like, seat, right, it could be the number of contracts that you’ve sold, it could be the number of companies you’ve sold into. So, if you sell into the two different teams within a company, maybe you sell to the design team and the product team and they’re on different contracts, is that one or two customers? If you sell to a company that has other subsidiaries, so like, ESPN is a part of Disney; if you sell to ESPN and you sell to Marvel, did you sell to Disney or did you sell to two different companies? So like, how many customers do you have?

Brian: Yeah, it sounds simple.

Emilie: What’s your expectation of the word ‘customer?’

Brian: Yeah. And that’s that data definitions, and that dance is something that often does need to happen. And I think helping a business stakeholder work through that, especially if this is, like, greenfield stuff where no one is actually defined that yet and it’s the first time, that’s where a team can really begin to show their value because it shows how you think about the world, you’re actually probably teaching the stakeholder something about, like, “Oh, I didn’t know—” they’re not going to say it in these words—“I didn’t know the data was modeled that way.” That’s probably not the words that they’re going to use to say it, but they’re probably going to start thinking differently about things when it’s like, “Oh, I didn’t know we had this concept of a subsidiary. Like, wait a second, maybe we should just go after the holding companies that we already have contracts with and get them to sign more of those because the MSA is already done. I didn’t know it was done that way.” Like, and now they’re now—the whole story has changed because you help them learn something about the world as it relates to the data piece of the business. I think there’s a needed step, a needed dance that has to happen. And maybe that doesn’t always happen. [laugh].

Emilie: My most viral tweet ever is this iceberg meme that I made. It’s actually my pinned tweet on Twitter. If someone were to go look me up, my Twitter handle is just my name. But at the top of it is pulling a number real fast, and then below it, where all the, like, surprise ice is and all the stuff that nobody realizes goes into running an effective data team, it’s like, aligning on the definition of customer, convincing people to track things before they want the data for it, like data warehouse permissions, telling people no, like, all these things that people forget goes into answering the right number.

There’s another meme—or not a meme, it’s a viral tweet by Seth Rosen, who’s a data product manager at Snyk, he was the CEO of TopCoat Data, and it’s something like, “Data practitioner gets an asks, and they write, like, SELECT from some perfectly designed table where I can just get the numbers for you real fast.” And I think about those a lot because, like, you know, as data people, we hear this and we’re, like, “Haha, that’s funny because it’s not at all what our jobs are like.” But the reality is like, that’s what other people think our jobs are like, and so there’s so much of a gap that it actually feels like an education piece.

To us another parallel it’s like, people will think design is just putting in colors that match together, like, or spinning the color wheel and seeing what lands. You know, there’s so much more to it. And it is an expertise; it is a domain that you have to develop. It’s certainly not like who’s really good at spreadsheets. There’s much more there. But I think when we have team members who actually develop it, we see what an impactful data team does to the business. So, it’s worth investing in giving people the time and space to develop it because your business will reap the benefits of it.

Brian: You’ve shared some really great insights here about you know, being empathetic to the people that we’re building these services for and doing all this, so thank you for coming on the show. I want to ask you about Locally Optimistic in a second, but can you tell me a little bit, like, the final thoughts, closing ideas for data science and analytics leaders and data product managers about just delivering better services that actually get used and increasing adoption of all this hard work that gets done in the data space?

Emilie: I think what I’ve really come to appreciate is how important the people side of things are first. And so, it’s about relationships, it’s about people, it’s about understanding the problems, much more than it’s about, like, fancy, cool technology or tooling or algorithms or languages. Like, we’re going to have culture wars on SQL versus Python for the next millennium, maybe. [laugh]. There’s a lot to go on there. But if we can focus on the people piece, understanding our customers—internal or external—understanding the problems we’re trying to solve, building up careers in data, and what, you know, 5, 10, 15, 20 years in the modern data stack look like, those problems feel much, much less solved, but, like, they continue to be the opportunity for us. So, I think it’s important, with all the cool engineering there is out there, just don’t lose sight of the people problems first.

Brian: It always boils back to that stuff, doesn’t it? [laugh]. In so many things, do. Emilie, thank you so much for coming on Experiencing Data today. I did want to ask you, what’s Locally Optimistic? You have some stuff there, some of these posts that we’ve been talking about? What is that?

Emilie: So, I will take almost no credit here. Locally Optimistic is a community of data leaders and data practitioners. So people, all levels of the career spectrum from thinking and figuring out what I want to be when I grew up, not in college, maybe in college, no job experience, to many, many years experience, former VP of Data, Chief Data Officer people. It started off as they Meetup in New York City and then moved online in, like, 2016, 2017. And the admin team has grown over the years.

It’s a blog and a Slack community, and it’s a place where lots of cool data people hang out. So, we talk about professional data things, but we also talked about, like, what’s the good book you read last week, and there’s a Slack channel for people like to do analytics on their runs, and running data like physical running data not, like, SQL query runs. So just, like, a bunch of cool data people trying to find community in other data professionals. And people have different opinions and one of my favorite things about it is that it’s just this vendor-agnostic community where you get all the benefits of going to a work conference regularly without any of the painful parts of travel.

Brian: Nice. Excellent. Well, Emilie Schario, thank you for coming on Experiencing Data again. It’s been a pleasure to talk to you.

Emilie: Thanks for having me, Brian. I really appreciate it.