Be a Data Wizard. Not a Data Monkey.

Let me be clear: there's nothing wrong with being the person at work who's tasked with getting the numbers right and helping people make data-driven decisions. It's awesome, in fact, if you're known as a data wizard.

However, we all know that feeling when we get a ping or an email, and it turns out to be a request for us to pull numbers and plug into someone's slide. We spend half a day on it, people happily take our input, and move on with their lives.

Then the same thing happens again. And again.

Of course, sometimes it's important, and you just have to do it.

Here's how I try to set boundaries.

#1 Do not set bad precedents.

Here's what I mean. If there are dashboards available and people still reach out for you to plug in data, don't simply acquiesce because you think it'll be faster if I just do it and get it over with. This lets people get away with laziness and creates the wrong incentives.

Instead, even if it takes you a little more time, show them how to fetch the data from existing dashboards. You can go so far as to even screenshot the steps for them and circle the resulting number. You want to invest time now, so you can save yourself time in the future.

As soon as you demonstrate that you're OK to pull numbers for something that should really be self-served, you set a bad precedent.

In fact, if any future questions arise about the data, they will come back to you with those questions, and take up more of your time. They will not see themselves as the owner, because they literally didn't pull it themselves! As a result, they will not be accountable for it.

Small actions can result in big differences.

#2 Ask people to articulate trade-off's.

While your data prowess may be a good reason for people to come to you, your time is an incredibly valuable asset. This means that even if you could easily fulfill someone's data request, you need to evaluate whether it's a good use of your time.

To do this, I ask people how they're going to use the data. They usually have a good answer.

Then I ask them what will happen if they don't get the data. That's when some people stutter.

You see, it is at this point that some people realize that they were never going to change their course of action, with or without the data. They simply wanted datapoints to make something look nicer or more convincing.

But they'll live, even without the data.

The other thing I do is I explicitly describe the time and effort it'll require of me. For instance:

• If it's an easy pull (and there's no easy self-serve channel), I tell them that it is a quick pull and that I am happy to help.
• If it's a non-trivial pull, but it's an extremely consequential datapoint, I tell them as well. I say that this will take me a full day, but that given the potential impact I will deprioritize other things to make time for this.

After all, your time is not just your time, but rather a valuable asset for the whole team. You are not being selfish by protecting your time: you are simply helping your stakeholders understand the trade-off's of spending your time on one thing over the other.

The additional benefit of this is that when you actually do invest your time and help, it is recognized as an explicit decision. It is not treated as simple tablestakes ("he's the data guy so he'll always give us what we want"). This makes it so that going forward, before people come to you, they will have a clear understanding of your prioritization principles, and make sure they are coming to you with something worthy of your time.

As a result, some trivial requests will also disappear before they even come to you, saving you more time in the future.

#3 Ask for the other person's time and engagement.

One of the most frustrating things is to be tagged on a document (with only two sentences' worth of context) and asked to do a non-trivial data pull. Sure, it might be important, but it's hard to muster up the motivation. Nor the confidence that it is indeed the right use of your time.

What you want to do is this: ask the other person to demonstrate that they care enough about it ask for your time. Ask them to meet for 15 minutes to ensure you have the full context behind the data ask. Ask them to walk you through how this datapoint will be used in their overall presentation.

This will help you tease out whether the other person truly cares (i.e. if they don't want to spend another 15 minutes to brief you, it probably isn't critical), as per point #2.

In addition, you also set a good precedent for the future. You are essentially saying something to the effect of:

...If you want to take up my time, no problem – but make sure it is something important in which you are personally invested as well.

Note that I am not suggesting that you push back on everything and make yourself difficult to work with. Surely we don't want that to be our reputation.

Instead, I am saying that there are smarter ways to tune out the noise, so that when truly important asks come in, you have a way to validate them and invest your time accordingly.

It should never feel like people are throwing data requests at you, and that you are serving them. Instead, it should feel like a two-way street: people are coming to you with a problem to solve, and they should demonstrate their seriousness by sitting down and helping you get as much context as you need to do the job well.

When people do that, I am happy to engage, and I will go 120% of the way for them. After all, I know it is important enough for them, and I have confidence now that it is important enough for the business.