Over the years I have had the opportunity to work for various companies, and no two onboarding experiences have been the same. In the data world, onboarding can become challenging if you have to set up numerous tools and adapt to an entirely new workflow. Some teams have robust and well-documented processes, whereas others have little to nothing documented or outdated documentation that hasn’t kept up with the changes that might have occurred over time. This is a reality with startups and well-established companies.

Onboarding is an art, not a science

What does it take to fully get onboarded into a role? How long does it take to be onboarded? These questions depend on where you are, your role, and your career experience.  

• As a newbie, the first 90 days is usually a good timeline to use to outline your goals for what you want to be able to accomplish in that timeframe.
• For the more seasoned professional, the focus should be more on what skills and strengths you want to be able to bring to the table within your first 6 months. 

Onboarding can be daunting, especially if you have never been onboarded for a technical role. From setting up your computer to making sure you have all the right permissions in place, these require keeping track of a long list of tasks and prioritizing the things that will allow you to hit the ground running. 

My goal through this post is to provide you with some guidelines for developing your own roadmap, which is an essential part of acquiring the knowledge, skills, and behaviors that will help you feel successful. The onboarding roadmap is your way of complementing the onboarding that will (hopefully) be provided by your manager. Expectations are usually anchored by the first projects they want you to be able to complete or get involved in. To get there, you need to have a solid foundation – this is where you can expand on your manager’s 30-60-90 day plan or whatever tool they might be using. 

• For the newbie
  • Your onboarding plan should ideally focus on workflow and setup and less on subject matter expertise and technical proficiency in all the tools. 
• For the more seasoned practitioner
  • The focus should be on workflow, documentation, and identifying the gaps that you can fill. As a more seasoned practitioner, you might also want to focus on understanding how the data team informs business priorities and contributes to growth and revenue gains. 

I don’t emphasize technical proficiency because that takes time and should be something you map out for yourself as part of your ongoing professional development plan and less as a focus of your onboarding.  

I’m going to focus on onboarding as an Analytics Engineer, but many of these concepts are applicable across all data roles. I am going to discuss four core categories and the approaches I typically take to shape my onboarding roadmap.  Use the following template as a companion to this post as you dig into these various topics. 

• Team Culture
• Setup and tools
• Workflow
• Documentation

Understanding team culture allows you to align your priorities with your team’s priorities

I find that being intentional about trying to understand the team culture helps you better align with what works for you as an individual and helps you identify the areas that might conflict with your approach as early as possible. Understanding this early will allow you to develop new approaches and communicate your needs. Some companies have written norms and values that they wish to abide by whereas others do not. No matter what is written, the team culture is often assessed by understanding the unspoken rules and seeing what leaders in the company invest their time and resources in the most. Culture is exemplified; it is not something that is presented in a glossy slide deck or blog post. 

As you onboard onto your new team it is helpful to take the time to understand the culture. The following questions are some initial questions that you can use to get started.

• What are the unspoken rules of your company and team?
• How do they go about defining success? 
• What are the team’s stated values
• What aspect of the team culture do you see exemplified?
• What does your company invest its time and resources in?

As an Analytics Engineer, I wanted to understand how the team and company culture impacted my work. From experience, I know that a company’s views and relationship with data and data functions heavily influence how things are prioritized and how work is allocated. 

Assessing the data culture

Things I looked for to understand the data culture at my current company

• What tools are available?
  • At my current company, there are a number of tools available to us for data analysis, data exploration, data cataloging, testing and monitoring, and data orchestration. Clue one for me was that investing in the right tools was something they were comfortable with and clearly valued given what exists.

• How does the company report on KPIs?
  • Company-wide KPIs are made available in our BI tool and shared widely across teams, with team leads adding some general overview and summary about what is most relevant to us. Data informs how we define success and how we should be thinking about it.

• How do teams use data to make decisions?
  • Some teams rely heavily on our outputs to make daily decisions and insights generated by my colleagues are used to inform processes, workflows, deliverables, and approaches. Data is valued here and is a natural part of how work is done here. 

Overall, I don’t feel like I have to prioritize proving the value of my role and my work as I onboard, because it is already part of the culture and an area of work that is prioritized for the company. If data is not part of the culture or prioritized, one thing you might want to consider is spending time understanding what the source of friction is for using data in your company. 

Here are some questions that you might consider investigating

• Who uses data?
• How is success defined across the company?
  • Is this based on data or not? If not, what seems to be missing? 
  • What opportunities do you see for using data to inform, tell a story or capture company wins?
• Who are the data champions?
  • What is their motivation for using data?

An efficient setup process allows you to work faster and smarter

When you jump into a new company you often have to learn new tools. You might be lucky and go somewhere that has the exact same tool stack, but even if that is the case it is rare for organizations to use the same tools in the exact same way. 

Use the following questions to guide your process and understanding of what to prioritize. 

• What programming languages will you have to rely on?
• How much of the data stack is already familiar to you and what will it take for you to get up to speed on those new to you? 
• Do you have to set up tools locally or are they cloud-based?
• Do you understand what tools are used for what?
• If they are not heavy on tools, do you have an understanding of how they approach data and think about data ingestion, transformation, and analysis?

As you start mapping out what you will need to get you up to speed you will need to focus on prioritizing the tools and processes that will enable you to add value now and balance that with learning brand-new tools and systems unique to your job. For example, if you have never used Git in the command line before, you need to decide whether it might be smart to focus on using a Graphical User Interface(GUI) like GitHub Desktop to ease your transition or taking the time to get really familiar with the command line (CLI) and shortcuts that you can alias. Time is your most limited resource, so prioritizing things that will allow you to jump into projects and debugging pipelines should be your focus as much as possible. 

• For the newbie
  • I find that setup can be overwhelming if everything is brand new. Think of this time as a great way to strengthen your problem-solving and hacking skills. If your setup process hits a number of roadblocks it’s important that you get comfortable “breaking” things. Breaking things is my practice of trial and error and getting comfortable with starting from scratch, deleting things, reading errors, and asking novice questions.

• For the seasoned professional
  • As more experienced professionals, we often have a few tricks up our sleeves and should be comfortable with tackling smooth and rocky tool setups. This is the time for setting up your local environment, requesting the right permissions, or setting up your preferred code editor with your go-to extensions, and other similar things. This is more of a time to inventory the tools and gauge what might be missing in your toolbox. 

Your company might have tools that address different parts of the data journey and understanding how these tools are used and fit into your workflow is going to be essential to your onboarding. In my previous company, we primarily used Fivetran, Snowflake, dbt, and Looker. In my current role, I have access to the same tools and more. I have shifted from Snowflake to Redshift, gone from limited testing and monitoring tools to a number of options including Monte Carlo, DataDog, and Sentry, and now work with extremely large datasets. 

Tools that I have access to span many different categories so I’m honing into the ones that I think will generate the greatest impact on my workflow and will bring me up to speed with concepts that I am not as strong in. These have been focusing on query performance and tuning in Redshift, getting really comfortable with our testing philosophy, and learning how to leverage our tools to better address data quality issues. 

Topic areas that every analytics engineer, regardless of experience, should make sure to better understand as it relates to their current data infrastructure are:

• The basics of your data warehouse.
• Data modeling and how it is approached at your company.
• Understand the process for testing and monitoring data pipelines.
• Data orchestration.
• Understand where your data comes from and how it is ingested.
• Have an approach for data exploration or know what tools help you explore your data. This can include data cataloging tools, documentation, lineage tools, and other similar things. 
• Understand how and where data is transformed.

Assessing where you are with navigating the tools

My favorite way to assess where I am in my onboarding journey when it comes to navigating the tools at my disposal is figuring out how comfortable I am debugging a pipeline. I ask myself the following questions which help me get a sense of how comfortable I feel about leveraging the tools at my disposal.

• How do we get alerted to an error?
  • Where do I go to read the logs?
• How is the data ingested?
• How can I get context about this pipeline?
  • Is there a data catalog?
• What is the downstream impact of this error?
• How can I look up lineage?
• How are findings shared?
• What are my resolution options?
• Where do I go to view data?
• What is the preferred tool for data exploration?

I use this to get a sense of how quickly I can dig into things. I pay attention to the areas that are most confusing and focus on building out a cheat sheet and asking my colleagues questions that help add clarity to this flow. This same process can be used to assess your comfort with your new workflow as well.  

Learn how work is prioritized, executed, and communicated

There are three areas that can inform your workflow. 

1. Understanding how you plan and execute work.
2. Providing feedback and informing the work being deployed by other stakeholders and colleagues.
3. Identifying areas of opportunity to improve processes.

Some places have prescribed workflows and follow agile methodologies or kanban and other places leave the workflow to you. Shadowing colleagues and asking the right questions when you can is a great way to get a better understanding of how work is planned and executed. Being able to articulate it for yourself will make you ready and more willing to jump into new projects. 

A common tool used in this space is Jira. I have an ambivalent relationship with Jira and agile approaches, but one thing I really appreciate is the ability to break down my work into chunks and document progress on it. We use a loose agile approach at my current company with a focus on documenting our progress and engaging with our stakeholders within issues/tickets generated in Jira. 

I do find having some way of keeping track of projects and their dependencies, and documenting progress, is essential to understanding the flow of a project. It also helps you to identify roadblocks and consistently keep track of important work. I always start very simply and outline my first few projects in a Google doc as I get familiar with what tools and approaches are used for planning and tracking work. This helps me stay organized early and helps me have one place to have all my notes and questions. 

In addition to planning and executing the work, you have to be able to leverage the tools at your disposal and be able to review other people’s work. Most analytics engineers work in a version-controlled environment which means someone will be reviewing your code before you can merge it and you would have to do the same for your colleagues. 

Use the following set of questions to build your understanding of the workflow and how work is prioritized. 

• How is work prioritized?
• How does the team track progress for deliverables?
• How does the team determine when a project is completed?
• What is the process for reviewing each other’s work?
• How is work communicated?

Assessing where you are with navigating the workflow

Understanding your new workflow and identifying the skills that you want to grow are going to help guide your approach. The following are my guiding questions for generally assessing my new workflow.

• Do you understand the workflow? 
• Where do you feel most confident jumping in?
• Do you understand how work is planned?

Another way I assess where I am in my onboarding process is my comfort level in jumping into reviewing Pull Requests (PRs). I use my answers to these questions to identify areas I need to dig deeper into or help guide my conversations with my colleagues. 

• Which ones do I find easy to review? 
• Which ones do I feel are difficult to review?

Knowledge sharing increases efficiency and skills development

As the latest hire, you will be pointed to the documentation that currently exists. As you get your feet wet and are navigating this new workspace it is also the perfect time to update your new company’s documentation. If it is unclear to you, it will most likely be unclear to whoever comes after you. A lot of times the prior staff were tasked with creating documentation out of nothing or having to document systems, processes, and expectations that they had already been doing for an extended period of time. This means that some documentation will be written with some unspoken expectations of prior knowledge about various topics or company norms. As new people come on board they are able to surface this information because they are more likely not to have this information. 

Knowledge sharing can be the most forgotten part of our work so I encourage you to think about documentation early on and use the following questions to map out where your company is in terms of documenting

• How much is documented?
• How much needs to be documented? 
• How much documentation is outdated?

Clarify everything, create cheat sheets for yourself, and take copious notes during your first few weeks in your role. These notes will help refine existing documentation or can become your outline for what documentation is needed. 

Assessing how things are documented

As a new hire, this is the best place for you to identify all that you wish existed to make your process easier and list out all that you think is still needed. Think of it as a letter to your younger self.  A helpful exercise after the first month is to think of all the documentation you wish existed and that you think would have made your onboarding easier. Revisit that exercise 6 months later and see if there is anything else that you could add to make the instructions clearer or provide added context that you didn’t have at the time. 

I have found that who we are at 1 month, 3 months, and 6 months are quite different. We amass a lot of excellent contextual knowledge that is often never captured but is extremely beneficial. This is when we start to develop our shortcuts and systems. 

Onboarding is also a great time for self-reflection

Onboarding is when everything is new again and we find ourselves in a space of discomfort and growth. I find it to also be a great time for reflection and a great time to evaluate career goals and aspirations. It is a time for you to reflect on what has worked best for you in the past, identify the areas you want to grow in early on, and work on the areas that can be the most challenging for you. It is also a time to set boundaries and define what you need the most out of a job. Many of us start a job wanting to prove ourselves and there is something important to that but the flip side is that you were chosen to do this job and you are more than capable to do it as long as you give yourself time to learn the ropes. 

Be intentional, don’t be afraid to slow down, and ask questions.