Your First 60 Days as a First Data Hire: Weeks 1-2

Welcome to Data Columns, a biweekly* community-led newsletter by me (Pedram Navid!) that brings practical advice about leveling-up as a data practitioner. My focus is bringing relevant, topical advice on practical matters that data people care about to your inbox.

In this inaugural post, I'll be giving the advice we all wish we had when we started as a first data-hire at a company. This series was a community-led effort, with some great advice from the broader data-community, and it wouldn't have been possible without everyone who replied to my threads and tweets, so a big thank you to everyone for helping me get started!

This will be a 4 part series with each part covering 2 weeks. We have plenty of advice coming from some very smart people, such as Erik James Mason, Sarah Catanzaro, Neal Coleman, to Kelly Burdine, Sam Bail, and Aditya Goyal, so make sure you subscribe to get notified when our next issue is out.

If you want to know more about the newsletter, or want to contribute, make sure you click those links to find out more! While this newsletter is sponsored by Hightouch, all opinions are mine, and not of Hightouch, and I'm fortunate to have been provided the space to write with editorial independence here to you. Now, with the intros, out of the way, let's get started!

Your First 60 Days as a First-Data Hire

This series is a practical guide for making sure your transition to a new role or company is successful, and it features advice from data veterans who have seen it all. By the end of this series, you'll have learned from our collective mistakes and hopefully picked up a few tricks to help make yourself more successful.

While this series is focused on the unique challenges of being the first data-hire at a company, I really believe there's some great advice in here for all data practitioners about managing their relationship to the rest of the company.

The Unique Challenges of Data Roles

Being the first data hire at a company can bring with it a lot of pride and excitement. There's something really motivating about being able to help solve pressing problems while setting the stage for the future growth of a data team. It can also bring a lot of pain and frustration when roles aren't clearly defined and when there's misalignment between your expectations and those of your peers and stakeholders.

Data often feels like a strange role, and I'm not quite sure why that is. Data management is nothing new, SQL itself is as old as the Walkman and Post-it Notes. It's easy to forget the past when it seems like everything is changing so quickly around us, but I don't think the difficulties in data roles are technical, but rather have more to do with the influence and impact data can have on the success and failures of the teams data people support.

All teams within an organization depend on data to understand their past and predict the future. When a sales team is comped on their sales quota, when a marketing team plans their ad-spend, when a finance team reports to the board, they all depend on data to do their jobs. People's jobs are often on the line when it comes to the numbers, and so data is by its very nature a very political beast.

This is a point easy to forget, but I think it's important to remember as we talk through some of the advice coming up for the first two weeks. In some ways, it's easy to see how selling the myth of data science as a pure form of mathematical truth-seeking to new grads eager to understand the world inevitably ends in job dissatisfaction and nihilism. Data practitioners aren't truth-seekers, they are mediators in a political battle with jobs, status, and dollars as the spoils of war.

With that said, I don't think data roles are doomed to be disastrous. I'm very proud of the data role I lead here at Hightouch, and I know there are others who really take pride in the work they do as well. Those that tend to have the most satisfaction in their roles also tend to understand how their roles are as much about influence as it is about numbers.

More importantly, there's lots of support out there. Data can be a lonely role, especially as the first hire. Between dbt and Locally Optimistic Slack, there's also Data Twitter, which can be a great place to meet some like-minded folks who have been through the trenches and have managed to still enjoy their job after it all. I highly recommend getting involved in these communities if you can.

Your First Two Weeks

It's tempting to try and produce value early on, and it's a good goal to try to accelerate as quickly as possible to what Michael D. Watkins calls The Breakeven Point in his great book, The First 90 Days (a book I highly recommend for anyone starting a new role). But, don't take too lightly the freedom you have in the first few weeks.

While you may have inherited a fire from day one (it's rare for a company to have the foresight to hire for data before their first data-disaster), you'll also find the first few weeks to be the only time of your entire tenure with this company where you will have made zero commitments.

In your first two weeks, your focus should be on understanding the business, getting to know your peers, validating expectations, and getting yourself organized so that you're able to apply what you'll learn in future weeks.

Before we dig into each of these steps, I want to emphasize that there's a real danger in thinking that what made you successful in the past will make you successful now. You likely were hired because you showed exceptional capabilities as a data practitioner on an existing team, but it's not data skills and the ability to write SQL that will make you successful as a first data-hire. You'll need to work some other muscles that may have atrophied from lack of use, but with persistence, thoughtfulness and a little practice, I promise they'll start to grow.

Know The Business

Understanding the business is critical for a data role. You'll need context on everything from how the product works, who buys it, and why. You'll need to understand what drives the sales, marketing, and engineering teams. This context will set the stage for how you build the data models that support your peers.

Your company may have a formal onboarding process (if you're lucky), but that should only be the beginning of your familiarization with the company and the product.

Try to get as much information as you can about the company's strategy, products, and structure. The company website is a great resource to get started on this, and may seem obvious, but is often missed. How the company talks about itself is valuable insight into its values.

If the product has a trial, go through its onboarding process. Take notes on how the initial flow feels to you, on any roadblocks you hit. It's likely that the product is so familiar to those who've worked there that they're unable to fully detach themselves from their knowledge of it, so a fresh perspective is often helpful.

Try to sit in on sales and success calls, you'll quickly pick up on trends and pain points. It's also very likely that the process sales and success go through will end up in your data warehouse, so understanding the data generation process can be really valuable.

Know Your Team

“The enemy is anybody who's going to get you killed, no matter which side he is on.” Heller, Catch-22

Another critical piece is to start forging alliances early. Find your champions within the company: the people excited to have you join, that are motivated by the potential a strong data-team can offer. You will need their political power to help get things moving, whether it's pushing for security to review your warehouse implementation faster, or for finance to approve the budget, you'll quickly find that even a one-person-data-team is no island, but part of a village of people who can either help or hinder your efforts.

Conversely, find your critics, those who doubt that the data team is well-equipped to answer questions, that believe that a data team's goals might conflict with their goals. You won't win everyone over, but it doesn't mean you shouldn't try to establish a relationship with them. In my career I've had my share of critics as I built up systems, often by those who felt like my work was encroaching on their territory. I could write novels about the different strategies you can employ to overcome this, but a simple one that often works is nurturing their ego. Find ways to compliment their intelligence, their expertise, and the hard work they've done as you approach them for questions or guidance. A little flattery can really go a long way.

Whether allies or enemy, you need to make a concerted effort to build lateral relationships with your peers. You will need them as you begin to institute change.

If you have direct reports, start thinking about how you want to build trust and communication with them. Find out what their preferred styles are. If this is your first management role, consider reading The Manager's Path, a great guide on what it takes to be a great tech lead or manager for a team, geared toward people graduating from IC roles.

You'll likely have those you report to. Figure out their reporting style, their communication style. Be explicit about your preferences to them as well. I find that managers tend not to be open about issues, especially to new hires, unless prompted. Make an effort to ask what their pain points are and who you should meet across the org as you like to effect change.

Know Your Role

Make sure you understand why you were hired, and continue to validate your understanding throughout your first 60 days, not just with your manager, but with their manager and your peers. The role of a data practitioner is rarely set in stone and the data community is still trying to understand what data people do, so don't be surprised when those who don't live and breathe SQL models have fuzzy ideas about what you were brought on to do.

In the First 90 Days, Watkins metaphor: 'recruiting is like romance, and employment is like marriage' says it best. Recruiting is about selling the role to the person you think is best fit to serve it.  Despite the questions you asked before you joined, you likely won't have a complete picture of the company you've married into until you're in the thick of it. It's common to find more roadblocks than expected, and to over-estimate your ability to influence change.

Getting clarity on your expectations will also help you understand the gap between your expectations and those your work with. Try to align some quick wins with what's expected of you to build valuable trust.

Know How To Listen

Your job will often be translating what people say to what people want. Realize that data literacy is going to be a challenge almost by definition if you are the first data-hire. Don't expect others to understand you or your work, or even what's possible, but listen carefully and practice probing questions.

I've often received questions for a particular piece of data, or a new sheet, or an extra column when I would first join a company. While it's sometimes easy to give people what they ask for, it's far more important and useful to dig into what they want. I tend to ask about the underlying use case, what problem are they trying to solve, and only after fully understanding it then focus on how to solve it. This process can also help prioritize work, while smaller quick-wins are needed early on, as work and requests pile on, being able to really understand the impact and scope of the work being asked for will be critical.

Understand that this way of working with data teams doesn't come naturally to people. A lot of what you will be doing is educating your peers on how to ask the right type of questions and how to make the right type of requests to ensure you and your team are consistently providing value. It will take practice and gentle reminders until they develop that habit.

Wrapping Up

I hope that was a helpful first look at what your first two weeks as a first data-hire might look like. I want to again thank all the contributors who helped make this post possible, and encourage you to leave feedback either right here or on Twitter, you can find me @Pedram_Navid.

If you found the post useful, I'd appreciate it if you could share it with someone else who you think might also benefit as we grow the community!

In our next post we'll take a look at foundational infrastructure, metrics, questions, and plans. Make sure to sign up if you haven't already to get notified when the next post is released. Thanks for reading!

* biweekly, as in every other week.