In 2021, I had the special opportunity to step into a “First Data Hire” role at Ramp. Looking back a little under a year and a half later, I’m grateful for the transformative experience that comes with that responsibility and wanted to share some of the biggest lessons I’ve learned from being the first data hire.

Narrow your focus

Before I joined Ramp, one of my major requirements for any new role was that the company must have a culture of making decisions based on data. After my interview with Ramp, I knew that was the case. What I didn’t realize at the time was how much data was available and how quickly it would grow.

Having a ton of data is not a bad thing, but as a first data hire, it can put you into quicksand. Coming into the role, I had a lofty goal to empower everyone with data. Immediately, I started to learn about the pain points of working with data across all of our departments. In each of these conversations, I promised different solutions and had quickly amassed quite the backlog of requests. I made the critical mistake of not taking the time to prioritize these requests.

It was daunting looking at the mountain of work. Everyone needed something, so I jumped in and worked on a little of everything.

The problem with this tactic in the world of data is that many data projects are circular in nature, and covering a wide breadth of work will quickly drown you. For me, these projects felt like fighting a hydra. Each time I thought a project was completed, two new projects would spawn in its place. I had already promised so much, and projects kept multiplying.

As a first data hire, you’ll want to help solve everyone’s problems, but time is limited, and you’ll need to narrow your focus for the best outcomes. Before diving into the core of your work, spend time understanding:

  • your company’s goals.
  • which department(s) drive those goals.
  • what projects will have an outsized impact on those goals.

Overcommunicate

During my early days at Ramp, I found myself only communicating results when asked rather than proactively updating my stakeholders. Layering on the mountain of work that I put myself in from not narrowing my focus, I figured that the best use of time was to focus on building.

On top of this, whenever I did respond, I oversimplified the work and the progress at hand to portray that everything was under control. In reality, I was under water and silently suffering. I felt that airing my setbacks would only bring down my reputation.

I found out the hard way that if you undercommunicate as a first data hire, it can (and did) lead to dismissal and distrust surrounding the data organization.

Since I was only responding when asked, I slowly eroded the faith of deliverables and expectations of a project. Stakeholders built this understanding that to get project updates, they needed to constantly reach out. My attempts to ease the disappointment of setbacks had the opposite effect and increased distrust! All of this culminated into a negative feedback loop for both parties. My stakeholders did not trust the output, and I was bottling up my anxiety, waiting for that next ping.

This lesson took me way too long to recognize, and I only connected the dots when my team hired an exceptional data engineer, Ryan D.

Ryan was tasked to tear down our orchestration platform and replace it with a platform that could scale with us. For us, this was moving from AWS Step Functions to Airflow. Immediately, Ryan began to overcommunicate with folks who cared about the project, starting a slack channel dedicated to the project and providing a consistent end of day response. Beyond an end of day response, any setbacks would be immediately aired in this public slack channel. Seeing the wins and losses communicated was new to me. I realized that no one was upset. If anything, folks were happy to be updated and that there was a new learning. The project ended up taking a bit more time than we had all anticipated, but was still deemed an outstanding success. Ryan’s communication style kept folks out of the dark and set strong expectations.

As a first data hire, you’ll likely have to juggle competing priorities. Losing the trust of your stakeholders can be a fatal mistake. Communicate in good-faith and when in doubt, overcommunicate.

Make it a priority to distribute your work

I have been an individual contributor for most of my career, which means I’ve typically have had a spokesperson to evangelize the work I produced. At Ramp, I naively thought that would happen again. I built and built, but never spent time actually distributing my work to the right folks. I thought that if I built this amazing dataset that everyone would want to use it!

A year later, I worked on a project to clean up all of the outdated models that the team has worked on and looked at the usage metadata. The model I spent a full cycle on a year ago has only been used less than 50 times in queries! How could that be? Baffled, I ask some folks why they don’t use it.

“I didn’t even know this existed—this is amazing!”

Special thanks to Ian M., our head of Data, for sharing this quote

As a first data hire, you’re likely going to be spending a ton of time building the infrastructure for your organization to leverage data. You should be spending an equal amount of time to distribute your work across the organization.