One Mindset Shift That Will Make You a Better Data Scientist

Actually, any good employee should adopt this mindset

After transitioning out of quant finance, my first experience as a data scientist was in consulting. Most of the feedback I received in my early days at McKinsey was not related to my code or technical skills, but rather consisted of advice like “you need to tie your work to the higher-level priority of the company/organization”, “you should add more crisp insights” or “you need to be more of a thought partner”.

At the time, being one of a few data scientists in a sea of consulting generalists, a lot of this feedback initially felt like fuzzy consulting jargon to me and I would have rather had someone critique my code. Now being a manager myself and looking back, I realize that these seemingly disconnected points are all related to one thing — the mindset I was missing back when I was a junior IC focused on polishing my technical skillset.

I was purely focused on execution instead of acting like an owner of the problem; however, thinking that my job was only to perform a task well was a mistake in hindsight. Over the years since then, I’ve grown convinced that an ownership mentality is one of the key things that sets high performers apart from their peers.

If you are thinking to yourself “this sounds very vague and abstract”, you are not alone. From my observation, most ICs struggle a lot with the feedback “you should adopt more ownership mindset”; which is probably why most managers prefer to give more tactical feedback about the “symptoms” mentioned above and not the core issue itself.

To make it less abstract and more actionable, I will attempt to break down the “ownership mindset” (or lack thereof) into the three most common manifestations I have observed among junior DS and talk about mindset shifts that can help you act more like an owner.

From jumping into “How we should do this?” to starting with “Why are we doing this?”

In order to come up with the best “How”, you need to first understand the “Why”. So instead of directly jumping into the solution, you should dwell a little longer in the problem space and truly understand why this work matters and what decisions or business outcomes it is supposed to influence.

Remember, every analytics problem started as an abstract business problem. But very likely, as a junior IC, when a project is communicated to you from your manager or stakeholder, some thinking has already been done on your behalf (i.e. your manager already did some scoping based on his/her understanding of the business ask). I would encourage you to probe for the original motivation behind the scoped-out analysis task. Understanding this will help you to make a couple of crucial decisions — how to prioritize this piece of work against everything else on your plate, who your key partner is, and whether you can propose a more efficient way to solve the original question.

For example, very often data scientists get what I call “data Siri questions” like “how many active users do we have?”. Once you pull that stat, you often get follow up questions (e.g. geographic breakdown of the users etc.). Before you know it, what seemed to be a 5-minute ad hoc data pull turns into 100 seemingly disconnected data questions.

The most efficient way to deal with these situations is actually to start from the “why”. When you understand that the PMs are trying to launch a new feature on IOS and need data to decide which countries to prioritize based on engagement, then you will be able to make suggestions on exactly what data cuts will be most insightful to answer that question; or, if you dig even one level deeper, you might pose the question whether engagement is even the right metric to prioritize countries. As a result of this kind of approach, you will also be viewed more like a partner who should be involved in the original scoping of the project instead of someone who only helps to pull data.

From “What do I NEED to do?” to “What CAN I do to help?”

Most junior ICs are passively waiting to be assigned to a project with a clear a scope and outlined steps so they can focus on executing. It’s not surprising because most of us grow up having someone telling us what to do, usually parents and teachers in school. Even in college, there’s a syllabus outlining the exact things we need to do to get an A. The good news is that managers usually don’t expect junior ICs to proactively scout and scope projects independently. But if you want to stand out from your peers and grow to the next level, that’s something you should be doing.

Instead of passively waiting for an assignment and only doing what is required of you, go above and beyond by paying attention in cross functional meetings and conversations you are involved in. If you tune your senses to spot gaps and needs proactively, you will notice the lack of data is frequently the blocker of progress and decision making, and that’s something the data science team is in a unique position to help with.

Spotting gaps and figuring out a solution to plug the gap is one of the crucial skills you need to possess if you want to be a tech lead or manager one day. Building up this skill requires getting rid of the attitude of “this is not my problem” or “I have no dog in this fight” and instead acting as a true stakeholder in the company’s success. This may sometime require you to step out of your comfort zone and extend your current skillset, but that’s exactly how you grow your skillset proactively.

From “This is the number” to “This is the takeaway”

Many ICs struggle to distill succinct insights from analyses they do; raw data dumped in a spreadsheet or document is rarely a satisfactory deliverable. To quote from a leader I respect a lot:

Everything we do is for the benefit of others. If others are not understanding or seeing the benefit of the work we do, our work is incomplete. Hence, communicating our work is as important as writing code and building the models and products to get the job done.

A data scientist’s job is to “drive business decisions through analytical insights” not “to pull the numbers and leave it to others to distill the insights”. Not to mention, the “pulling numbers” piece is the easiest part for AI to replace.

Imagine you are the reader/consumer of the analysis instead of the one conducting it. Without any in-the-weeds knowledge about the analysis, can you quickly distill what it’s trying to do and what the takeaway is? Is it clear why engineers, PMs etc. should care about this work? If not, you have not succeeded at communicating insights through your analysis.

Conclusion

Remember you are the sole owner of your career and every project that powers it. So taking the initiative to make it more successful is your responsibility and yours alone. Adopting this mindset definitely takes time and practice; but once you master it, it will benefit not only your career, but also your personal life once you start applying the same mindset to everything you do.