Having a job in data & AI means doing. Doing. Doing.

We do projects. We create datasets, pipelines, dashboards, agents, apps. We have deliverables and results and demos. In all the noise of building and demonstrating, we forget that a good part of a senior data professional's job is to say no.

Hear me out.

Data is there to serve the business. And we should serve it well. But not every project should be built the way the first draft suggests. Some dashboards should never be built at all. Some automation and agentic AI should not be implemented. Because of overlap with existing systems, because of incomplete data, because of a misunderstanding of the underlying business process. And above all, because of a low or negative ROI.

As I grew from a newbie to a senior consultant, I learned to embrace this part of the job. I advised my clients, sometimes to their displeasure, to do things differently, or simply not to do them at all. Some accepted immediately. Some were skeptical and then came around. Some went ahead anyway.

Here are six examples from my portfolio of NOs.

NO #1. The middleman nobody needed

Their first ask: Act as the contact point for extracting operational data from source systems.

The business analysts needed small quantities of highly specific data from source systems. They were trained, capable, and perfectly equipped to extract it themselves. A direct extraction would put no meaningful load on the source system.

My presence in the middle would only slow them down, add more latency, a dependency, and a bottleneck. I refused the role and suggested the BAs access the data directly.

The client accepted. The BAs were happy and motivated. More importantly, they started to see me as an ally rather than a gatekeeper. They began coming to me regularly with the requests that actually needed my skills: higher volume extracts, complex transformations, recurring pipelines.

NO #2. The data model that was the real problem

Their first ask: Make our dashboards faster.

The dashboards were fully optimised. Queries were tuned, filters were in place. But performance was still poor. I dug into the data model and found the real culprit: a fully normalised model being used for reporting.

Every analyst had to understand the join logic. Every query risked duplication due to different granularities across tables. The model was technically correct and practically painful to work with.

I recommended denormalising for reporting purposes. The client resisted; they believed a normalised model was the industry standard and the right way to do things. It is, but for transactional systems. For reporting, it's often the wrong choice.

We made the change. Dashboard performance improved. Development speed improved. And analysts stopped needing a data architect in the room every time they wrote a query.

NO #3. The shadow pipeline that would have become the same problem

Their first ask: Build a shadow data pipeline because the internal data team is too slow.

The frustration was real. Deliverables were taking too long, and the business wanted a workaround. But when I looked at why the internal team was slow, I found structural constraints: approval processes, infrastructure limitations, and team size. A a parallel pipeline would immediately inherit those constraints. The shadow flow would become just as slow, and now there would be two slow pipelines instead of one.

I proposed a different approach: work with their data team, inside their existing infrastructure, to help them move faster.

The client agreed. I built datasets within their standard environment. The work was harmonised with their existing systems and handed off to their own team to maintain, leaving no dependency on an external consultant.

NO #4. The "master source" that would have mastered nothing

Their first ask: We are exploring a completely new businessprocess. Build us a master dataset, an OBT that covers every present and future use case.

I understood the appeal. One table to rule them all. But the dataset was complex, with multiple granularities that would collide in a single flat table. The resulting OBT would be enormous, slow, and require specialist knowledge to use safely, because without understanding the grain, analysts would inevitably produce duplicates.

I suggested a different approach: identify the four or five actual use cases on the table right now, and build focused datasets for each one. Simpler schemas. Faster queries. Immediately usable by analysts without a data engineer in the room.

The client accepted. The focused datasets were in production quickly, analysts adopted them without friction, and we avoided building an expensive monument to hypothetical future requirements.

NO #5. The AI that was solving the wrong problem

Their first ask: Use AI to extract structured information from candidate CVs.

This one came from inside. I was leading recruitment at my previous company, and my boss was adamant: we should use LLMs to parse CVs and pull out the data points we needed.

I pushed back. If we needed structured information from candidates, years of experience, tools used, specific qualifications, linguistic competences, why not simply ask them directly? A few additional fields on the application form would give us clean, structured, reliable data. No tokens. No probabilistic extraction. No edge cases caused by unusual CV formatting.

The LLM approach would have introduced complexity and cost to solve a problem we had already created ourselves by not asking the right questions upfront.

We updated the form. We got better data, faster, for free.

NO #6. The full picture that didn't exist

Their first ask: Track everything about our customers.

The client was in hospitality. The ambition was understandable: a complete view of customer behaviour across every touchpoint. But when I mapped the available data sources against what "track everything" would actually require, the gap was significant. The data to support full tracking simply wasn't there, and connecting to additional sources would have meant major infrastructure work, for a partial result at best.

I asked them to slow down and do something harder: formulate their actual questions. What decisions did they want to make? What behaviour did they actually need to understand?

Once those questions were on the table, the answer became much simpler. A handful of focused reports covered the real needs. No data model overhaul. No new source connections. No months of work chasing a complete picture that the data couldn't support anyway.

Building your own portfolio of NOs

The common thread across these six stories is diagnosis before prescription. In each case, the initial ask was reasonable on its face, but the real problem was something different, and the proposed solution would either not solve it or make it worse.

Saying no well requires a few things:

• Enough technical depth to see past the surface ask and understand what's actually going on.

• Enough business context to know what actually matters to the people making the request.

• And enough confidence to deliver an uncomfortable answer and still be heard.

In a field where doing is worshipped, I would encourage you to advocate for thinking before doing. Not everyone will appreciate it in the moment. But the clients who do — and there will be more than you expect — will come back.

Over time, your diagnosis, your pushback, your willingness to say the uncomfortable thing, will build a reputation that delivery alone cannot create. That's your portfolio of NOs. And unlike dashboards, it never goes stale.

What's in your portfolio of NOs? I would love to hear your examples in the comments.