enabledat

By Edris Yaghob//3 min read

Say no to the data requests that aren't worth your time

A data steward's inbox is a queue of other people's certainty. Most requests do not earn the work. Here are the questions, and the scripts, to say no without sounding difficult.

A data steward's inbox is a queue of other people's certainty. Add this field to the critical list. Build a rule on that one. Define this term by Friday. Each request arrives sure of itself. Most of them are not worth the work they ask for, and saying yes to all of them is how your week disappears into data nobody decides anything with.

You do not need to be difficult to say no. You need a few questions and the language to go with them.

First, the one question that does most of the work

Before anything else, ask what breaks:

If this data is missing, wrong, or stale, what specifically goes wrong, whose decision depends on it, and whose phone rings when it fails?

If they can answer in one sentence with a name attached, the request is probably real. If the best they can do is "it is important for reporting," it is not ready, and you have your opening.

The script: "Happy to take this on. Help me size it first. What decision breaks if this field is wrong, and who feels it? If we can name that, I will prioritise it. If we cannot yet, let us hold it until we can." You are not refusing. You are asking the request to earn the work, and most vague ones quietly withdraw.

Then, sort the real ones before you act

A request that passes the first question still might not be the work they think it is. Two quick sorts save you from building the wrong thing.

Is this about the values, or the meaning? Ask: "if the value were perfectly correct tomorrow, would this be solved?" If yes, it may need a rule. If no, the meaning or method is contested, and a rule will not touch it. No point building one.

Is the term actually agreed? If three people would give three answers about what it means, you are looking at a definition problem wearing a data quality costume. Route it accordingly.

Why this protects more than your calendar

Every field you add by status instead of evidence, every rule you build without a consequence, every definition you file that nobody asked to settle, becomes maintenance you carry forever. Saying yes is not free. It is the most expensive thing a steward does, because the cost shows up quietly, for months, as a critical list that bloats and a rule library that cries wolf.

A good no keeps your attention on the few elements that actually drive decisions. That is not being unhelpful. That is the job.

When the questions are hard to hold

The pressure is real. The requester has a deadline and a manager. Holding the questions when someone wants a yes today is the hard part, and it is where most stewards cave and add the field.

That is the work enabledat is built to hold with you: it runs each request through the same questions, so the answer you give is consistent and defensible instead of a judgment call you have to win alone every time.

Say yes to the work that protects a decision. Say "not yet" to the rest. Your week, and your data, will thank you.

Request early access to the beta.

Turn a data problem into a usable outcome.

Request early access to beta