Down with 'data science'

Your company has one definition for revenue across the organization, one definition of customer, and one definition of sign up.

For people whose jobs are so defined by ensuring we’re aligned, we can’t seem to standardize on one definition for Data Scientist.

In this talk, I propose we lobby against the title Data Scientist, instead choosing some variation of the Core Four Data Roles: Data Analyst, Analytics Engineer, Data Engineer, and Machine Learning Engineer. With clarity around role definition and role delineation, we can create clearer career paths for data professionals, resulting in us elevating the profession.

Follow along in the slides here.

Browse this talk’s Slack archives #

The day-of-talk conversation is archived here in dbt Community Slack.

Not a member of the dbt Community yet? You can join here to view the Coalesce chat archives.

Full transcript #

Anna Filippova: [00:00:00] Hello, and thank you for joining us. I call us my name is Anna Filipova and I head up community here at dbt Labs. I’ll be the host of today’s session. The title of the session is Down with "Data Science" and we’ll be joined by the very esteemed Emilie Schario. Emilie is currently the data strategist in-residence with Amplified Partners. And that means she has one of the coolest jobs ever. She gets to work with many different early stage startups and help shape their data strategy as they grow. You might also know her from her prior role at Netlify, where she led data and business intelligence or her time consulting on internal data strategy.

Last year, she brought us one of the most memorable talks of the conference. Why You Should Run Your Data Team Like a Product Team. And today she’s about to shift our understanding of roles on data teams. Are you ready for this? A gentle reminder that all chat conversation is [00:01:00] taking place in the #coalesce-down-data-science channel of the dbt communities.

Please do ask other attendees questions, make comments or react at any point in the channel. Also remember to use slack threads to keep the conversation tidy. After the session, Emily will hang around in the Slack channel to answer your questions. So throw them in the chat anytime, and we’ll make sure to come back to them.

Get started over to you.

Emilie Schario: Thanks, Anna. I’m so happy to be here. I’m I don’t know if you can tell, but my excitement is like physically palpable I’m so honored to be speaking at Coalesce again on day two it’s the dbt community has meant so much to me and my career. And so being able to be a part of this, to be a part of the community, to be part of.

Coalesce is just so meaningful to me personally, I’m really excited to convince everyone here today that we need to get rid of this phrase, data science. And I hope you’ll stick around on this journey with [00:02:00] me. I do want to echo, please do join the Slack channel. After this. I have time carved out today and probably for the rest of the week where I’m going to be going and engaging with you all in Slack.

I really want to start a conversation here today. A little bit about me like Anna mentioned, I’m currently a data strategist in residence at amplify partners. I was previously director of data at Netlify. Prior to that, I was the first data analyst at get lab and a couple of other companies I’ve gotten to work with a variety of organizations.

I use she her pronouns today. We’re going to talk a little bit about what science is, and then we’ll talk about what data science. Are what data science is and what data scientists do. We’ll talk about the work that data teams are doing, the core four roles that you should have on your data team, career paths, and how, at the end of the day, this is all about leveling up the data profession.

[00:02:55] What is Science? #

Emilie Schario: So let’s start with this question. What is Science? [00:03:00] Hopefully you’re racking your brain now to like elementary school or high school or the freshman year biology class. And the great thing is for all of us that we have search engines that can help us come up with really great definitions here.

Wikipedia came through and told me that science is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe, or to put it more. Simply science is a systematic enterprise for obtaining knowledge through testable explanations and predictions.

Only you think when you read this definition, hopefully what comes to mind is the scientific method. We see something, we research what already exists about it. Reform a hypothesis, a we actually experiment on this, we analyze data and then we share our conclusions and that should draw and create another question.

And when Alexis Johnson, Gresham and Katelyn Mormon publish this blog [00:04:00] post on linear and circular data projects in 2020, I think this is what they were getting at. Some projects are clear, cut and dry. There’s a start and an end, we did the thing, you check it off and then other. Their work actually leads to new questions and that’s the circular piece.

And so what we’ve heard so far, what we’ve read, what we’ve talked about in science is that science is experimentation. And so my question is do the people who hire data scientists know that I did what any reasonable person here would do. And I went to the dbt jobs board. And I asked the dbt jobs board , dbt jobs board.

You have a data science category. Tell me what do data scientists do? So I looked at this job description. I’ve blacked out the company name here for protecting the innocent. Let’s say, do you see experimentation on here? I [00:05:00] see optimized. Building refactor pipelines build visualizations. So experimentation, maybe it’s a fluke.

Let’s look at another. Oh, I see statistics right there. Uses appropriate statistical. Huh? Weird, no experimentation. We said science is experimentation. So do the data scientists know that Josh Will’s a very esteemed member of the dbt community. So is that a data scientist is a person who is better at statistics than any software engineer and better at software engineering than any statistician.

[00:05:36] What’s in a name? #

Emilie Schario: Okay. Whereas experimentation. And then there’s this blog post from Lyft where they say, and we can read this together at Lyft we’re rebranding our data analysts function as data scientists. So a data scientist is a data analyst.

And when we think about the kinds of work that data teams do, [00:06:00] we have operational analytics, metrics, management, data insights, servicing other people, and yes, experimentation reporting and experimentation is a part of what data teams do, but it’s not the only thing that data teams do. And the thing folks is that words matter language matters and yes, job titles too.

[00:06:23] Building a data team #

Emilie Schario: They matter. I shared this name earlier in the year on building a data team in 2021. And as the year comes to a close, we roll into 2022. All of this is still true. And so people think building a data team is pulling a number real fast, but there are all these things that happen under the hood. And one of them, the one that’s relevant for us today is standardizing on the definition of.

We know that standardizing on the definition of customer is important because when someone says, how many customers do we have? You don’t [00:07:00] want to reply, do you mean accounts, teams or users? And so we know that words matter in the context of our work. And so word language, job titles, matter in the context of our own.

So before we go into solutioning, let’s take a step back and say, what is the purpose of the data? And I say that it’s to help the organization make better decisions. And this was our mission at the, at Netlify the data team mission out Netlify the data team exists to empower the entire organization to make the best decisions possible by providing accurate, timely, and useful insights.

And here are the beautiful humans behind that Netlify data team who really are challenging the norms on how most data teams are run. And I think that if this were a panel and they were all up here with me today, what they would say is that while experimentation is a part [00:08:00] of what data teams. It’s not the only thing or even the core thing.

[00:08:06] The Core Four #

Emilie Schario: And so our job titles should be a reflection of the skills we have, not the domain of work we do for the business. So instead of ambiguous titles, like data scientist, I propose that we use these core four roles and this a lot of information on a screen. So let’s look at a simplified version. Data engineers move data from outside of your ecosystem in analytics, engineers, work with data within your ecosystem, data analysts, present insights and analysis, your stakeholders and machine learning, engineers build and productionize machine learning models.

If you’ve ever interviewed with me, you’ll know that I say I’m hiring for floor sweepers. This is someone who is not going to be afraid to take out the trash, if that’s what needs to be done in the moment or sweep the floor or whatever [00:09:00] it is. We all have to be willing to do whatever work needs to be done.

But the question here is, does your title reflect the kind of work that you’re doing most of the time I’ve written about these core four roles before on the writing analytics job description, section of the analytics engineering. But when it comes down to is we should organize our roles this way, because instead of dividing people on whether they do or don’t work on experiments or how well recruiters have to, or don’t understand the jobs they’re asking of people, job titles should be reflective of the work we’re asking people to do.

This is the five kinds of work your data team does. And in the same way, experimentation is just a piece of it. We shouldn’t have a person who’s only on experimentation in the same way. We wouldn’t have someone just to manage our operational analytics things. So [00:10:00] let’s do that thing that teen magazines do where it’s if you select a, your result is.

If you’re first data hire, we’ll use you UI-based EL tools and manage snowflake permissions end-to-end and be responsible for data warehouse design, you should call them an analytics engineer. If you’re first data hire we’ll write custom ETL to support custom data sources, occasionally implement custom event tracking into your application or be responsible for your data warehouse design.

You should call them a data engineer. If your first data hire will be a hundred percent focused on surfacing business insights, you are setting them up for failure because there are other things that need to happen first. And so the way that a lot of organizations end up with this data science hire is that they know they need data, but they don’t know what that means.

And so they just go with like big data science, because it sounds like the right combination of buzzword. But this should be a flag to us as data [00:11:00] professionals. And so maybe you’re sitting there right now thinking like Emilie , I know what my job is and I have the tunnel of data scientist. So what does it matter that it’s not clear to other people?

I talked to a lot of people about careers, like a lot of people about data careers, and a lot of them have this rough path. You come in, you get your first job. Things are going well, you get that intermediate title. And then a couple years later you get promoted to senior.

Congratulations, crushin it. So happy for you. And then you’re posed with this decision. Do I want to go to the management route or do I want to go the technical individual contributor route? And if you make that technical individual contributor role in data, that’s it, right? What comes next? I don’t know.

You die, right? Like your career is that’s it. And I know people are like, no they’re principal and fellow or whatever the next level is. Okay. [00:12:00] Honestly, have you ever actually seen a principal data analysts in the wild, like really, if you have let me know, cause I’m all yours. And in fact I did what any good data person does.

And I tried to get some data about this. So I asked LinkedIn, how many principal data analysts are there. And LinkedIn said 1600. I said, thank you very much, LinkedIn. But I really had no context. Is 1600 a lot .Is 1600 a little. So I say. LinkedIn, how many analytics engineers are there. And LinkedIn said, emilie, there are six times more analytics engineers than there are principle data analysts, six times more analytics engineers than there are principal data analysts.

It seems to me like the principal data analyst is more of a unicorn than all these tech units.

The analytics [00:13:00] engineering job title didn’t even exist until a couple of years ago. And people have been data analysts for a long time. And so what we’re saying to folks is, yeah, you can get to the staff level, but then your career is. You cannot grow. And in fact, if we look at what’s happening, we see that people are recognizing that and they leave data.

They move into chief of staff or biz ops or finance roles. They move on from our data organization. But we absolutely cannot. Attrit our best talent. If we’re going to leave and have the kinds of organizations we want, yesterday Tristan handy and Julia Schottenstein and Martine Casado in their conversation about how big this wave is.

We’re saying really big. I’d encourage you to go catch up the session, but thank folks. I’m going to be really Frank here. If we attrit [00:14:00] our best talent, we are handicapping this way. We cannot have our best talent feel that there is no career opportunities in data. If we’re going to make the difference and create the impact that we want to have.

So here’s my proposal. We need to create career ladders for each of the core four roles. That includes a path for technical mastery data cannot be management or settle for staff. We have to create opportunities for technical mastery, and I’m not the first data person to talk about careers in data.

Katelyn Mormon has a three-part series on locally optimistic, published last. On why you need a career ladder and how to use it. I would definitely encourage you to go give it a read. My point here today is that data scientists is a bad job title and data [00:15:00] science is a bad descriptor because it’s highly unspecific and not reflective of the majority of the work being done by data teams.

It’s important to align job titles, to skills, development, and career progression on a team and not the type of problem being solved or the tool you’re using. This is why things like look at Mel developer or Tableau analysts are also bad job type. We need to create opportunities for technical mastery careers for each of the core four roles, especially data analysts, and hopefully you’re sitting or standing at your desk and not.

Yes, this makes sense. You see this problem in your org and maybe it even feels like this conversation has been happening in the zeitgeists for a little bit. And I think it’s because we have, so in mid November, Ben Stansell wrote about the missing analytics executive for his sub stack. Around the same time he [00:16:00] recorded an episode of the sequel show with Boris Jabez , where he had the same conversation.

I think actually the podcast inspired the sub stack. And then back in October Stef Olafsdottir of AVO and Laurie Voss of Netlify had a similar conversation where they talked about how companies often use this data scientist job title as a crutch. And then just last week, not so standard deviations hosted by Roger Pang and Hilary Parker had a really interesting take on this where someone from the audience sent in a letter and what they said in this letter was like, "Hey, my current job title is data scientist and excuse me, but I do all these other things in my job like what should my job title actually?". And Hillary says don’t veer from data science as a job title, because it does pay more than other job titles. And the more you can keep the air of mystique around what you do, the more you’ll get paid. And the sad [00:17:00] fact is that this is a hundred percent true. This is totally true.

Data scientists make more money than a lot of their other data peers. This is optimizing for the short term salary bump. And instead we should really focus on solving the problems with why there’s this ambiguity and this era of mystique in the first pit first. And this is still a conversation that is happening.

The analytics engineering podcast in September had an episode with Tristen Handy and Julia Schottenstein and Caitlin Colegrove where they talked. One of the things that came up was how data analysts are seeing. As less respected than software engineers. And then just a couple of weeks ago in the analytics engineering Roundup, Tristan wrote about the future of analytics in companies and how we’re actually going to see a big dispersion of analytical skills.

And then the subsequent analytics engineering [00:18:00] Roundup, and our wrote about how there are six ish jobs to be done. Indeed. And I think what all of these conversations come to, what this talk, what talking about the types of work that your data team does, what all of this is getting to is that we want to elevate the data profession.

We know that our orgs can be more impactful to the business. And one of the ways we do that is by removing the ambiguity of this data science. Thing title language descriptor, and this data scientists job title that goes with it. If we’re going to level up the impact that we have to the business, the starts by leveling up the clarity and the organization that we have when we talk amongst ourselves.

So hopefully your head is still nodding. This is all making sense. You’re onboard with me. And you’re like, so what do I do about it? It would be hard to have [00:19:00] this conversation. Candidly, if we didn’t also recognize that people like the data scientists, branding data analysts are often seen as lowly number Fetcher’s and data science has this like aura mystique.

And so it’s seen as prestigious, usually data scientists get paid. But if you want to make a difference here, I think that there’s a lot that we can do. Not just if you have this data scientist title, but first across the board, get clarity on your title, independent of what it is, catalog the work you’re doing for your organization for a milestone or two, which of the five categories of work are taking up the most of your.

[00:19:42] Get Clarity on Your Title #

Emilie Schario: And then reflect not just on the work you are doing, but on the kind of work you want to be doing. If you’re going to have a conversation about careers with your manager, it’s not important. It’s important that you know what you are doing and make sure your title reflects that. But also that you have a plan to help you get to more of the work you [00:20:00] want to be.

Go ahead and share with your manager and team members, why you’re spending time understanding what job titles actually meet. And if that means you want to borrow these slides to use as the foundation for a lunch and learn, shoot me an email. I’m happy to help make that happen. Finally work with your manager to adjust your title with your HR org and how this plays out.

It’s actually going to be really specific to you and your organization, but having a candid conversations can help shape what that process looks like. The other thing we can all do is remember to elevate data analysis. The engineering part of what we do can seem really attractive. It can be trendy. But recognize that insights come from many types of work, not just experimentation.

And then also amplify and share the insights that you were a team member of yours is finding throughout your organization. There’s a great blog [00:21:00] post from August by a staff data analyst at Netlify Paige Berry on how. Excuse me, share your data insights to engage your colleagues. Next we can elevate data practitioners together.

So Sarah, who I work with here at Amplify has this wonderful tweet thread on the importance of bringing data practitioners to the boardroom. But there’s a lot more, there are a lot of other rooms besides just the boardroom. So create opportunities for data practitioners to be in the room where the decisions are.

But also create opportunities for them to be doing proactive, work, help break teams out of that service. And finally remember that data, people should report to data people. And this graphic comes from a really phenomenal blog post by Eric Bernhardsson. But remember that data people are just as entitled to managers who understand their job [00:22:00] as the rest of the organization.

And if you want to see or hear about a team that’s doing this really well, I would encourage catching up on Erica. Louie’s talk from yesterday, scaling knowledge. Is greater than scaling body. So we’ve done it. Hopefully you’re all convinced this data scientist’s job title has got to go. I want to take a second before we move into questions to recognize that while I might be up here giving this talk today, this is really a conversation that I’ve been having with the community for many months.

When I first wrote this proposal for coalesce six or seven months ago, it was an idea with a couple of pages scribbled. But this talk is the culmination of many conversations I’ve had with people. Since I’m glad to see that a conversation around data careers is so front and center right now, a lot of people like to talk about tools are trendy and companies building those tools are really cool.

[00:23:00] But tools are nothing. If we don’t center the people using those tools in our conversations. Let’s keep this conversation going, please do let me know what you think in Slack, but I think we’re going to bring Anna up here and we can jump into some questions.

[00:23:22] Q&A #

Anna Filippova: Thank you so much, that was so much fun. And I know you can’t see the Slack right now, but it is blowing up with nodding emojis. Folks are absolutely loving this. Let’s start with a question from Amanda. And Amanda says the most important question is where can she get any on data, light sign, like yours

Emilie Schario: Lets see. I, yeah, just ordered it off Etsy. I can find the exact shop I used and send it to you in slack later.

Anna Filippova: Awesome. Okay. Serious question. Dave of Jack Connors thing yesterday wants to know Dave says, I feel like we’ve seen a lot of analysts move into analytics engineering [00:24:00] because currently leveling up in analytics seems more synonymous with gaining technical expertise.

How do you envision leveling up for analysts without moving into the eight lane?

Emilie Schario: Great question. I think this is actually a scope of influence question. So when people talk about like manager, director, a senior director, and then VP at the manager level, you influence your team. And then at the director level, you influence your department and VPs influence the whole company, right?

Excuse me. I think the leveling up for data analysts needs to be thought about in a lot of the same way. So for a data analyst, maybe you’re supporting a pod and then or really advising a pod and surfacing insights that affect that. Excuse me, but then as you move from from senior to staff and up and above at some point and this is what Ben gets to Ben Stansell gets to in that chief analytics [00:25:00] officer is that chief analytics officer is really like the data analyst who most closely surfaces insights to the CEO and is really driving things that change the company.

Perspective perception. I don’t, I think we have to try it out and we have to create paths where we’re going to do this and get it wrong a little bit. But in the process of getting it wrong, we’re going to get it.

Anna Filippova: I love that. The journey is very much not done yet. We’re still in this together and there’s still much more learning to do related to this question from Emily. Emily says one separation between data analyst and data scientist. I’ve seen is technical tools they use, which is something you mentioned in your talk earlier.

BI tools, Tableau, Excel, maybe SQL versus R and Python. If we do away with the data scientists. Do we need to differentiate within data analyst somehow based on this?

Emilie Schario: No, we need to decide what tools our teams are using. [00:26:00] So if you’re going to be using so, okay. When I first joined that. We had some people who liked R and some people who liked Python.

And one of the first things I did was say, we’re not going to support both. And the reason for that is because when your org is like this big, it is very hard to support multiple languages. Maybe only one person knows R and then they leave or only one person knows Python, and then they leave. And now there’s all this stuff to maintain.

It is very hard to support a lot of tools or languages. For the same purpose. So I think as an org, you decide what your right tooling is, and then everyone of your team uses that tool. And whether that’s an org that is comfortable with both Python and SQL or R and SQL or R and Python or whatever it might be, I’m not going to dictate your tooling to you.

But that seems like an artificial way to break down who is doing what. [00:27:00]

Anna Filippova: Thank you for that. GAM wants to know and specifically says "yes, exclamation mark bringing data practitioners to the rooms where decisions are made is what we should do. However, how do you make that happen when it’s definitely not anchored culturally speaking?"

Emilie Schario: Yeah. Yeah. It’s a hard problem. And I won’t say it’s not or pretend it’s not In a lot of ways, the way we get data, people in the room is that we get people who see the value of data in those rooms to bring us in and. I think one of the best ways to do this, isn’t to try to go really wide and shallow in who you, as the data team work with, but instead to serve a few stakeholders very well.

And find an executive or a department that you can really understand the problems that you can help them with. And let them see the value of the data team, earn that Goodwill [00:28:00] be useful. And then when you say, "Hey, can I actually get an invite to that meeting so that we don’t have to play telephone afterwards?", if they will be much more amenable to that ask because they’ve already seen the value of you and your team.

Anna Filippova: One question for you back on career tracks and career progression. Steven is asking, "is this a natural progression of a field as a field evolves, does it just naturally become more specialized? Is that what is that what’s happening here or is there something special and different about data".

Emilie Schario: Good question. This is what I’ve been thinking a lot to myself too. So I work with a lot of earlier stage companies and they’re like a lot of times people, their interaction non, non data stakeholders or data stakeholders in those companies. There are previous interactions with the data team is primarily with data [00:29:00] analysts.

So when they come in to these earlier stage companies, they say, we need to hire a bunch of data analysts and they don’t understand the bigger picture. I think part of the blame here is on us as data people, not doing a great job, helping other people understand the challenges of our roles and yeah, there’s some level of just like maturity of data and clearer definitions and and the, an efficiency that we’re going for by defining the roles this way. But there’s also some level of this is work that needs to get done. And we haven’t done a great job of explaining that to people or communicating that to people.

Anna Filippova: Questions just keep pouring in, keep them coming folks. Greggor says that they’ve only worked in small companies so far and have never thought about talking to HR about the name of their job. They just put whatever they thought fit in the moment into their email signature and on their [00:30:00] LinkedIn.

Is there anything wrong with that?

Emilie Schario: Titles matter because they help communicate expectations. And what I mean by that is Your title matters to you because it helps people understand, helps other people in your org understand how to interact with you. You know that you’ve got someone in HR because they’re titled tell you that tells you that they’re in HR.

And so if you have a question about your. Salary, you might go to the person in HR, or if you have a question about your payroll, you might look through your org chart and say who’s got payroll and their job title. So job titles matter because they help us understand how to navigate our organization.

That’s like an internal use case, but there’s also an external use case here that like, I’m really glad that you’re happy at your current job. And you’re good planning on staying there and maybe you don’t care that much about your title. But I’ve interviewed a lot of people in the last year. Like [00:31:00] a lot of people and a lot of candidates come to me with the state of scientist’s job title.

And my first question to them is, so what does data science mean to you? And the vast majority will say something of, oh I’m a data analyst. My company just calls it data science and yeah, why not just call it what it is, we, when we. We want everyone in the org to know what customers means.

We want everyone in the org to know what revenue means. And so we need everyone in the org to understand what a data analyst versus an analytics engineer versus a data engineer is. And the ambiguous title of data scientist or whatever your title might be, being more exact with. It is going to be able to communicate.

Internally and externally the kind of work you’re doing.

Anna Filippova: Got a really related question to [00:32:00] what we’re talking about. So I’ll just jump into it. I’ve heard of defining a data science team of a small group of analysts, engineers, rather than hiring a data scientist to do everything and companies before.

Do you think data science will become a team rather than a single role?

Emilie Schario: I think we should just call it data teams. There’s a lot more, if we think about that definition of science, there’s a lot more beyond just science and experimentation that data teams are doing. So I think data is a better umbrella term than data science.

There are companies with a lot of data science teams and. Always in my experience, those teams are a collection of people with the data scientist job title. And so it’s possible, but I think that’s still too ambiguous and we would be better off just having data teams.

Anna Filippova: What do you think about the term decision science or?

Emilie Schario: Yeah so I am not a fan of the business intelligence term. We’ll start there. I’m not a fan of the business intelligence term because. [00:33:00] It feels like business intelligence or so I’ve seen like business intelligence analysts, business intelligence engineer, and it feels like people with this business intelligence title really they’re just like glorified dashboard builders.

And that term just has a lot of baggage with it at this point. And I’m not sure that’s a great branding for us either. Decision science is an interesting one because. It helps like this inclusion of the word decision helps us. Think about what the goal here is, which is really driving to a decision as quickly as possible, helping the org make better decisions.

And so I’m more okay with that. I think that makes a lot of sense. I think it becomes weird when you have a team of like data engineers, analytics, engineers, and decision science. I’d probably ask, like how much science are they really doing? If you’re just getting or updating revenue [00:34:00] numbers, doing decision science, I think what we’re better off doing is leveling up or more clearly articulating and showcasing the value of folks with that data analyst.

Rather than rebranding, but if what it takes to get people in the room, if what it takes to have the impact, we need to get data analysts, the salary they deserve is that we have to rebrand it to decision analysts or decision drivers or analytics translators is another one I’ve seen.

Anna Filippova: I like translators Calen wants to know and I think this is actually really important to talk about in this context. So when you remove data scientist, as a role in a data team, does the analyst swallow all their skills and responsibilities? How can we distinguish between analysts who are focused on dashboarding and reporting, and those who conduct more deep dive analysis, modeling, machine learning, regressions, etc.

Emilie Schario: There’s a lot in that question. [00:35:00] So let’s start with where do these responsibilities go, and I’d start with saying that. Probably those responsibilities already fall into one of the other core four roles that I’ve laid out. So if they’re building machine learning models, the responsibilities go to the machine, learning engineers.

If they’re building a dashboards or reporting those responsibilities, go to the data analysts. If they’re building out dbt models, those responsibilities go to the analytics engineers. And so most of those responsibilities already exist in your organization. It’s a question of where they live. If you’re following this core four roles fleet framework, the second part of the question.

I remember there was a second part, but Anna, maybe you can come off mute and repeat the second part there. Cause it escaped me.

Anna Filippova: Yeah, you got it. The second part is how do we distinguish between analysts who are focused on dashboarding and reporting and those who conduct more deep dive analysis, modeling, machine learning and regression.

Emilie Schario: Yeah. We’ll [00:36:00] take machine learning out of the picture there for a second. Cause I talked about where that’s going to land, but the rest. If you think it’s important to differentiate, you put a comma after their job title, and you say that so data analysts, comma regression or data analysts come a dashboard.

But the reality is that for the vast majority of orgs what we need is people who are able to do that whole breadth, the whole. The whole breadth of work. And so you might build a dashboard today and then you might print a regression tomorrow. We shouldn’t say these are the only things that belong to a data analyst.

We should be making it easier for data analysts to do the most impactful work to the organization and then make it as easy as possible for other people to do the lower level or. Not necessarily re the responsibilities that should belong only to the data team.

Anna Filippova: I love that. There are a couple of [00:37:00] questions on hiring and I’m going to try and summarize them because they both have the same underlying theme.

There’s a lot of leverage that you’ve talked about in calling someone a data scientist as a hiring manager. Why would I throw that away? And if I let’s say I’m bought in, okay. I’m not going to hire data scientists anymore. How do I attract talent?

Emilie Schario: I think the idea. Like the data scientist job titles should be a flag to people at this point.

It’s ambiguous. Nobody knows what it means. It’s just and so if I were looking for a job, I wouldn’t want the data scientist job title. It’s like saying I’m okay with things that are confusing and an org that doesn’t understand what they’re asking me to do. And so as data practitioners, we should actually want more exacting titles.

The other hand, the other side of that as a hiring manager is that I have this thing, [00:38:00] the spiel that I go on when I interview people and I always say I think 80% of the world’s problems are expectation mismanagement. So we’re gonna set some ground rules for this interview. And I think, Hey, I’m getting your job.

Title is the ultimate expectation management. It’s saying, here’s what I need you to do to be successful. Here are the skills that I expect you to have and aligning on that with the candidate before they even apply is the clearest way to make sure that you’re both aligned on what the goals of this role.

Anna Filippova: Will has a question about experimenting. You mentioned earlier in your talk that a lack of experimentation is one of the things that is a problem right now with folks who are employed as data scientists is your only qualm with the role of data scientists, the lack of experimentation in the job description.

And if experimentation is part of the role, is it okay to have a data science.

Emilie Schario: No, because we [00:39:00] shouldn’t, we wouldn’t have a operational analytics scientist, right? Like we wouldn’t have a data, operational analytics analyst. We shouldn’t give people titles that are about the kind of work we’re doing.

We give people titles based on the kinds of skills they need. You have a front end software engineer and a backend engineer, not like. The person who updates the about page. Like it’s a silly title because it doesn’t mean anything because there’s not a standard to the org. It’s not necessarily that it’s only about experimentation it’s that if science is experimentation and data science is running experimentation, the fact that this job is not primarily doing that means that the title doesn’t make a lot of sense in a lot of ways.

And even where that is the primary responsible. Of the individual, there are other kinds of work that we ask them to do. And so we shouldn’t give them a title. That’s about this tiny sliver of the impact they have on the [00:40:00] organization. There are so many other ways that people get insights, not just experimentation.

Anna Filippova: We have time for one more question. And this is a long one, so I’ll try and summarize. Okay. Kyle is asking how can we convince analyst focused data roles to separate themselves from data scientists, especially when data scientists will be paid more, even if their function is exactly the same. You also mentioned that organizations view analysis work as less valuable, hence the pay.

So do the analyst take one for the data team as they always do.

Emilie Schario: This really falls on leadership. It’s on folks like me, who, when presented with. Split in the road to go the senior technical individual contributor out or go the manager route, and they chose management. This is on us to fix, we have the power here.

And the answer is we have to fight for the comp bands for our data analysts that is reflective of the impact that our data analysts [00:41:00] have to the company. On the other side of it. We all need to be emphasizing the impact that data analysts have. So highlight those insights that they’re finding, share it widely, not just within the data team, ensure that data practitioners are getting in the room as often as they can and have data people report to data people.

The only way that we have the movement that we need is if we have data organizations being impactful to the organism, being in fact impactful to the larger company.

Last modified on: