Your First 90 Days as a Data Scientist

I DoorDash about five months ago. That is my first time starting at a brand new company as a Data Science Manager. DoorDash moves fast, expectations are high, and the domain context is deep, which makes onboarding difficult. Nonetheless, it has also been considered one of the fastest-growing periods of my profession.

The primary three months at any latest job are fundamentally a constructing phase — constructing connections, domain understanding, and data knowledge — and a smooth onboarding sets the muse for later success. Due to this fact, in this text, I’ll share what mattered most at first months and my checklist for any data science onboarding.

I. Construct Connections 

Before anything, let me start with constructing connections. Once I was in school, I pictured data scientists as people spending all day long heads-down writing code and constructing models. Nonetheless, as I became more senior, I spotted that data scientists make real impacts by embedding themselves deeply within the business, using data to discover opportunities, and driving business decisions. This is particularly true today with tighter DS headcount and AI automating basic coding and evaluation workflows. 

Due to this fact, constructing connections and earning a seat on the table must be a top priority during onboarding. This includes:

• Frequent onboarding sessions along with your manager and onboarding buddy. These are the individuals who best understand your future scope, expectations, and priorities. In my case, my manager was my onboarding buddy, and we met almost day by day throughout the first two weeks. I at all times got here with a prepared list of questions I encountered during onboarding. 
• Arrange meet-and-greet calls with cross-functional partners. Here is the agenda I normally follow in those calls: 
  • 1. Personal introductions
  • 2. Their focus area and top priorities
  • 3. How my team can best support them
  • 4. Any onboarding advice or “things I should know”
  • I especially just like the last query because it consistently provides great insights. Five years ago, after I onboarded at Brex, I asked the identical query and summarised the responses into categories here. The very best I got this time is “”
• For those key partners, arrange weekly/bi-weekly 1:1s and get yourself added to recurring project meetings. You could not contribute much at first, but just listening in and collecting the context and questions is useful.
• Should you are onboarding as a manager like me, you must start talking to your direct reports early. During onboarding, I aim to learn three things from my direct reports: 1. Their projects and challenges, 2. Their expectation of me as a manager, 3. Their profession goals. The primary helps me ramp up on the realm. The latter two are critical for establishing trust and a collaborative working relationship early on.

II. Construct Domain Context

Data scientists succeed after they understand the business well enough to influence decisions — not only analyze outcomes. Due to this fact, one other priority during onboarding is to construct your domain knowledge. Common strategies include talking to people, reading docs, searching Slack, and asking a whole lot of questions.

I normally start with conversations to discover key business context and projects. Then I dig into relevant docs in Google Drive or Confluence, and browse Slack messages in project channels. I also compile the questions after reading the docs, and ask them in 1:1s.

Nonetheless, one challenge I bumped into is digging into the rabbit hole of docs. Each document results in more documents with quite a few unfamiliar metrics, acronym names, and projects. This is particularly difficult as a manager — if each of your team members has 3 projects, then 5 people means 15 projects to catch up. At one point, my browser’s “To Read” tab group had over 30 tabs open.

Luckily, AI tools are here to rescue. While reading all of the docs one after the other is useful to get an in depth understanding, AI tools are great to offer a holistic view and connect the dots. For instance,

• At DoorDash, Glean has access to internal docs and Slack. I often chat with Glean, asking questions like “How is GOV calculated?”, “Provide a summary of the project X, including the goal, timeline, findings, and conclusion.” It links to the document sources, so I can still dive deeper quickly if needed. 
• One other tool I attempted is NotebookLM. I shared the docs on a selected topic with it, and asked it to generate summaries and mind maps for me to gather my thoughts in a more organized way. It may well also create podcasts, that are sometimes more digestible than reading docs. 
• Other AI tools like ChatGPT also can connect with internal docs and serve the same purpose.

III. Construct Data Knowledge

Constructing data knowledge is as essential as constructing domain knowledge for data scientists. As a front-line manager, I hold myself to a straightforward standard: I should have the opportunity to do hands-on data work well enough to offer practical, credible guidance to my team. 

Here’s what helped me ramp up quickly:

1. Arrange tech stack in week one: I like to recommend establishing the tech stack and developer environment early. Why? Access issues, permissions, and peculiar environment problems at all times take longer than expected. The sooner you may have the whole lot arrange, the earlier you’ll be able to start fiddling with the info. 
2. Make full use of AI-assisted data tools: Every tech company is integrating AI into its data workflows. For instance, at DoorDash, we’ve got Cursor connected to Snowflake with internal data knowledge and context to generate SQL queries and evaluation grounded in our data. Though the generated queries usually are not yet 100% accurate, the tables, joins, and past queries it points me to function excellent starting points. It won’t replace your technical judgment, nevertheless it dramatically reduces the time to first insight.
3. Understand key metrics and their relationships: Data knowledge not only means having the ability to access and query the info, but understand the business from an information lens. I normally start with weekly business reviews to seek out the core metrics and their trend. This can be a terrific solution to contextualize the metrics and have an idea of what “normal” looks like. I’ve found this incredibly helpful when gut-checking analyses and experiment results later.
4. Get your hands dirty: Nothing enforces your data understanding greater than doing a little hands-on work. A great onboarding program normally features a mini starter project. At the same time as a manager, I did some IC work during my onboarding, including opportunity sizing for the planning cycle, designing and analyzing multiple experiments, and diagnosing and forecasting metrics movement. These projects accelerated my learning excess of passive reading.

IV. Start Small and Contribute Early

While onboarding is primarily about learning, I strongly recommend starting small and contributing early. Early contributions signal ownership and construct trust — often faster than waiting for a “perfect” project. Listed here are some concrete ways:

• Improve the onboarding documentation: As you undergo the onboarding doc, you’ll run into random technical issues, notice broken links, or find outdated instructions. Not only overcoming them yourself, but enhancing the onboarding doc is a terrific solution to show that you simply are a team player and have the desire to make onboarding higher for future hires.
• Construct documentation: No company has perfect documentation — from my very own experience and chatting with my friends, most data teams face the challenge of outdated or missing documentation. As you might be onboarding and never busy with projects yet, it’s the right time to assist fill in those gaps. For instance, I built a project directory for my team to centralize past and ongoing projects with key findings and clear points of contact. I also created a group of metrics heuristics, summarising the causal relationship between different metrics we learned from past experiments and analyses. Note that each one these documents also turn into invaluable context for AI agents, improving the standard and relevance of AI-generated outputs.
• Suggest process improvements: Every data team operates in another way, with pros and cons. Joining a brand new team means you bring a fresh perspective on team processes and might spot opportunities to enhance efficiency. Thoughtful suggestions based in your past experience are super invaluable. 

In my view, a successful onboarding goals to ascertain cross-functional alignment, business fluency, and data intuition.  

Here is my onboarding checklist:

1. Week 1–2: Foundations
   – Meet key business partners
   – Get yourself added to core cross-functional meetings
   – Understand team focus and priorities at a high-level
   – Arrange tech stack, access, and permissions
   – Write your first line of code
   – Read documentation and ask questions
2. Week 2–6: Get your hands dirty
   – Deep dive into team OKR and commonly used data tables
   – Deep dive into your focus area (more docs and questions)
   – Complete a starter project end-to-end
   – Make early contributions: Update outdated info, construct one piece of documentation, or suggest one process improvement, etc.
3. Week 6–12: Ownership
   – Have the option to talk up in cross-functional meetings and supply your data-informed perspective
   – Construct trust because the “go-to” person to your domain

Onboarding looks different across corporations, roles, and seniority levels. However the principles stay consistent. Should you’re starting a brand new role soon, I hope this checklist helps you ramp up with more clarity and confidence.