The Eternal Suffering of Data Practitioners: Part 1
A totally scientific extrapolation from a small and biased sample
A few weeks ago, I posted an opportunity for mentorship to data practitioners who needed someone to talk to. I received far more responses than I could ever hope to fulfill, but I read through every single one. Since I could only select three people to work with, I decided to pull out the main themes I saw and address them as best as possible.
The Servicing Framework Gap
"I'm the sole data person and consistently feel like I'm playing defense in service of countless requests. I don't have a great framework for answering questions as they come in."
This is a common refrain I've heard, especially as data teams are small, yet stakeholders seem never to stop growing. Part of the problem is that the framing of the question implies that your job is to answer requests. When you're the only data person at the company, answering questions should only be a small part of your job.
Forget everything you know about data, and pretend for a moment that you are a senior executive. What would you spend your days doing? If you're an executive worth keeping, your job is to invoke maximum impact on the organization, given your limited availability. You should be laser-focused on providing maximum leverage. A VP of Sales doesn't spend all day doing outbound cold calls, even though they might be quite capable of closing deals. When they are on the phone, it's to get a big deal over the finish line right before the end-of-quarter.
If you're the VP of Marketing and the product team came to you and said they need a post in two days on some feature that is about to launch, and this is the first you heard of it, what would you say? If you were told to send an outbound email and were given the subject line and content, would you take that well?
"But I'm not a VP of Data. I'm a data engineer. I'm a data analyst. I'm the manager of analytics."
Get over it. A title is what you list on your resume. Your job is what you make of it. Stop taking tickets if you don't want to be seen as a ticket-taker.
Okay, now that I've stepped off my soapbox. Here's some actionable advice.
Train Your Stakeholders
If you're a victim of unreasonable requests, you first need to work on the supply side. I find that stakeholders don't know how to ask data teams for help. They'll do everything except what you want them to do, whether it's a quick question for a number without context or a detailed description of how to pull data along with every column required.
Kelly Burdine, in a thread in Locally Optimistic, shares her team's Acceptance Criteria for requests. These fields in an intake form are the first step in teaching people how to ask data teams for help.
In many ways, you need to act like a PM. I asked the "so what problem are you trying to solve" question many times, and I've gotten nicknames based on it. It's tireless work, but it's a continuous reminder to teams that your job isn't to take orders; it's to help make impactful decisions using limited resources.
If a team can't articulate why they want access to data or what decisions they will make with the data, or if there's no clear indication that the request supports a goal or KPI, then it's time for the requestors to step back and spend more time thinking about what they want before coming to you. I know that sounds scary, but Hallowe’en is around the corner, so get comfortable with being spooked.
As your company and team grow, some type of intake form is inevitable. Still, you might be fine with a Slack channel for free-form question-asking or even email in the early days. A dedicated Slack channel for asking for help with data is a great place to generate awareness amongst your peers of the types of questions people ask. With Slack workflows, you can create simple templated forms to help structure the requests.
I recommend starting with the least amount of questions possible and increasing them over time. Striking the right level of friction is more art than science, although you can't go wrong with this question from Caitlin Hudon.
Prioritization
Inevitably, you will get more requests than you can answer with the time you have. You also need to realize that your job has more facets than time spent responding to questions. A prioritization framework can become complicated, often looking at multiple dimensions, such as urgency and impact. But, in the early days, prioritization can be simpler: focus on one executive you're going to support and ignore the rest.
It all comes back to the role you're in. You're here to have maximum impact. Start with the CEO and work your way down. If you can align your work with the CEO, then there's little anyone can say or do to attack your priorities. That's not to say you can't help the rest of the organization, but the more you can align your work with helping the CEO make better decisions, the better. In doing so, making a case for scaling your team will become easier. More on that soon.
Failures in Thinking Strategically
"How do I think strategically? I never have the time."
Hopefully, I've convinced you that you need to act like an executive, even if you aren't one. If so, then this next argument will be even easier for me to make.
If you are not spending time at work thinking strategically, you are not doing your job.
What does strategic thinking mean? Everyone has their definition of what strategy is. For me, a data team's strategy is thinking about the approach you will take to address the company's needs over the medium to long term.
It starts with thinking. If you do not have time to think, then you will not think strategically. Block time on your calendar. Get a notebook and leave your phone behind. Sit down and think for an hour about how well or poorly you are serving the company's goals and how you will serve them as it scales and grows. What is the vision for the company? What do the founders and executives talk about at all hands? What are the headwinds, and where are the pain points? Are we concerned with growth, retention, expansion, sales, churn, hiring, revenue, and costs?
Your strategy is both what you will focus on and what you will say no to. Be explicit, write it down, and share it with your boss. Get alignment.
Here's an example scenario.
We have been growing successfully over the last two years. Still, sales cycles have increased over the past quarter, and we missed our revenue target for the first time. There's a clear focus in the market on cost containment. We are planning on raising funding over the next 12 months. Our focus as a company over the next year will be to shift from logos to revenue, improving our sales efficiency and reducing spend where possible.
My strategy will be to align with our VP of Sales to get her everything she needs to hit our revenue goals. Our VP of Marketing will be my next closest ally. I will work with the two of them to help sharpen our understanding of our inbound leads through enrichment, optimize our pipeline by analyzing sales rep performance, and help figure out which channels drive the most revenue and which channels are underperforming. I may need to invest in certain tools or even outsource some help, especially when it comes to marketing channels.
As I won't have time to service the needs of the rest of the organization, I'll need to hire an analyst or double down on self-service capabilities.
When your strategy is set, you've solved many downstream problems for yourself. I'll often get a question like "what do I build first," "how do I plan for the future," or "how do I divide my time between answering questions and building scalable systems," but these questions are all symptoms of a lack of strategy.
Start with strategy, then the answers to these questions become more manageable. Without it, there's no framework for answering them well.
Loneliness is such a sad affair
And I can hardly wait to write SQL again.
I can't count the times I've looked longingly at engineering teams as a sole data hire. Yet, they are reviewing each other's PRs and discussing trade-offs and architectural decisions. Meanwhile, I'm commenting on my GitHub issues, trying to act like I have friends.
Loneliness is the one thing no one prepares you for as you build a career in data. It's why I think communities like dbt and Locally Optimistic flourish. We had to expand our reach to find just one other person who feels like we do. It's what makes Data Twitter, despite its flaws, so great. It's why I started a LinkedIn group for data practitioners.
My only advice here is to engage in the communities and create your own. I wouldn't be where I am today if I wasn't relentless in the questions I ask. I learn more from others than I hope to learn on the job.
There's only so much time I have available. I made myself available to three people for mentorship, and there were 27 others I had to say no to.
That's why my last request is if you've benefitted from a community and have the time to dedicate to even one person once a month, reach out and let me know. Hopefully, we can find more mentorship for the other 27.
Coming Up
That's it for Part 1. In Part 2, I'll cover three more common questions: Scaling a team, building a data culture, and the ever-nagging question: "am I doing this right?"
This is just great advice even outside of the sole data practitioner - align your focus/time with the business!
I *love* the question about "what's more important, accuracy or speed"