I Kicked My Analysts Out of the Data Warehouse (… And Why it Benefits Analysts!)

(originally published in 2025)

Last month, we made the decision to kick our analysts out of the data warehouse. I believe this is the best thing we could have done to empower both our organization and our analysts to be successful. Without this change, we open ourselves to data trust issues and unintentionally hinder our analysts’ success. If you’re an analyst, you may not agree with me yet — but I think you will by the end of this article.

To understand why revoking access can be a good thing, we have to feel the pain caused by the alternative. Only then can we appreciate the advantages of distributed responsibility. Let me transport you back to a board room discussion of yesteryear… (based on real events, with details changed to protect the guilty).

It was a balmy Thursday in February, and I was feeling pretty bullish about the roll out of the new Business Intelligence program at my company. In a short time, we had digested several large core datasets and built a suite of reports that served many of our key stakeholders. Marketing was happy. Product was happy. Finance was happy. I was happy.

As I walked into the boardroom that day, I felt a quiet pride. Seeing our reports displayed on the screen was deeply satisfying and something that would not have been possible only a few months prior. The work behind creating the datasets and getting company buy-in was both significant and complex. The relief of seeing these efforts used organically in a company meeting was a great reward for the labor.

Unfortunately, my self-administered pat-on-the-back was abruptly interrupted by an exclamation from the head of marketing. “Wait, how did you get those numbers?!”

Creating value in an organization is a risky proposition. It’s inherently political and often requires compromise. The best solution is not always the most cost-effective. The most technically accurate is rarely the most popular. Working with data can feel very empowering and it is possible to move very quickly with the right access and software capabilities.

In this case, my analysts had direct access to our data warehouse. After all, why shouldn’t they? They were trusted, talented, and motivated. My goal was to enable them — to grease the wheels so our BI platform would see broader adoption.

But that access was a double-edged sword.

Let’s pause to define the term “analyst” — because it’s a spectrum and I think it’s often misunderstood. Very few data professionals focus 100% on creating reports for stakeholders. In reality, most report authors are embedded in other roles. That is, someone whose full-time job is something else (managing, working a queue, selling, or developing), but has displayed a keen eye for patterns. They have been recognized by their superiors, which has undoubtedly earned them a side-of-the-desk job writing reports. In this context, success is often derived from focus, finding 3–6 uninterrupted hours of time to knock out the latest quarterly report, or improve a repetitive process by automating numbers.

If this is you, I want to encourage you — full stop. I have been there. I remember the rush of discovering SQL and Power BI, and the thrill of solving real-world problems with data. It’s addicting. It’s fulfilling. You are probably looking for a way to make this your full-time gig.

But, hold on! The grass isn’t always greener on the other side.

As someone who does work with data full-time, I often lack the domain knowledge you bring. I don’t know the intracacies of your work queue, the pain points in your process, or the subtle patterns you see every day. It’s not my world! That knowledge is incredibly valuable. You are valuable because you straddle both worlds. And, while I hope those skills are increasingly recognized and rewarded in the marketplace, that’s a topic for another time.

My point is this: the hybrid analyst role is incredibly effective — and incredibly common.

Having clarified what I mean by “Analyst,” let’s return to the thesis question: “Should you have access to the Data Warehouse?” Let’s continue in the board room of yesteryear to see how this plays out …

“Wait, how did you get those numbers?!” exclaimed our CMO. “Mine are off by about 5%!”

My dopamine high quickly crashed into cortisol. I jarred my attention back to the screen assessing the claim and trying to make sense of the discrepancy.

Ah, a simple mis-understanding, let me clear this up.

“I see what’s going on here,” I chime in, “Marketing bases their revenue off of website sales. Since warranties and returns are handled outside of the website platform, those figures aren’t included here.”

There was a tenuous pause as the room watched the CEO, looking for an indication of whether this answer was acceptable. Regrettably, the silence was cut short, by a third opinion.

“Actually, my numbers are different, too,” injected our lead Sales Manager.

Genuinely surprised, I turned to the Sales Manager to press further.
“How are your numbers different? You are using the same report as Marketing, right?”

Sheepishly, the answer slowly followed: “Well… the same data, but when I report sales, we take into account sponsorships and affiliates, so that can offset a portion of the revenue”

“I’m not sure I follow, is this just an issue of filtering? Could you share the filters you are using in this report and we can compare with what the marketing team uses?”

My tempo had increased, acutely aware of the waning available time before the CEO would make his voice heard. I needed to contain these loose ends quickly, ideally while showing how the integrity of our BI platform was never in question!

“Actually…” came the dreaded response from sales. “… I am using the same data you gave me access to, but I created my own query and then pulled that into Power BI. It wasn’t that hard and you showed me how.”

The volleyball I thought I had returned was now sailing past me, untouchable. What was this phantom report — this rogue query? Why had it been published and shared without my knowledge? Had any of it been validated? Who had already seen it and made business decisions with it? How was I expected to be accountable for numbers presented from a completely different data pipeline?

The “How” turned out to be an easy question to answer as the CEO shifted in his chair and began to open his mouth…

I sincerely hope you haven’t been caught in a position like this — it’s not fun! If you have, you already understand why limiting access to data can be a good thing.

If you haven’t had this experience, and you’re an analyst, I owe you an answer. Why is this better for you? After all, you’re not standing in the board room under fire! You’re on the front lines. Your stakeholders have specific needs. Cutting off access makes your job harder, right?

To answer this, we need to zoom out. Data Warehouses often contain disparate data requiring varied levels of masking, sensitivity, and security. The data pipeline is often sensative to timing, requiring finely orchestrated refresh sequences to keep data fresh and relevant. A more advanced data lake environment will have sets of transformations layered on top of the raw data, organized into datamarts which may carry their own row-level security. Suddenly the term Data Governance pops up, requiring steering committees and organizational buy-in. Did someone say compliance? We’re not in Kansas any more, Toto…

Note: If you’re salivating right now, you may be ready to make the transition from “Analyst” to a full-time “Enterprise Data” role. But, if this seems more daunting than tantalizing, then maybe you’re beginning to understand the implications that come with direct access to the data warehouse. Still, cutting you off isn’t the answer. There is another way.

How do we give analysts the data they need — without opening the floodgates and causing more problems than we solve? Data in a mature organization follows a hub-and-spoke model, governed centrally by a team who deals with the hard questions full-time (the “hub”). This is consumed by analysts who are distributed globally and innately familiar with the specific questions asked in their respective domains (the “spokes”).

In order for this model to stay healthy, the hub must listen. The spokes must be able to request. This may look like a ticket queue, or an internal forum, a weekly sync, or a task board. The mechanism doesn’t matter and those details depend on the nature, size, and culture of your business. The spirit is the same — collaboration is required.

And with that collaboration comes the analyst’s holy grail: focus.

As an analyst who fights to carve out time to build with data, you are now unburdened by the problems of the infrastructure, but still have an avenue to provide your feedback and request enhancements. When you succeed at carving out that chunk of 3–6 hours to build your next masterpiece, you can work freely within your domain, relatively carefree from the politics of role-based permissions, PII/PHI sensitivity, or data freshness. Your spin-up time is shorter, your list of pre-requisites lighter, and your work product is simpler. Now there is time to perfect that KPI calculation, beautify your pixel-perfect splashpage, or write that long-overdue email to convince your local bean counter why they should be using your report.

Looking back at that chaotic boardroom moment, I now realize how much smoother things could have gone. With tighter controls, dataset creation would’ve been centralized. Metrics and definitions could have been unified. Analysts would have inherited consistent, curated data — and stakeholders would trust it more! Difficult questions about access, or ownership could have been resolved by a Data Governance committee and my CEO would have ultimately never had to think about these problems.

Perhaps the conversation would’ve gone something like this?:

“Wait, how did you get those numbers?!” exclaimed our CMO, a fire lighting in her eyes.

“Check the tooltip on that scorecard,” I replied, “You’re each looking at different business objects — one for website revenue, the other for sales revenue. The data dictionary link explains the difference.”

“Ah, okay. I didn’t realize we had that,” subsided the CMO, flame extinguished.

“Now for our next item of business …” Once again, I felt the cool breeze of relief as the eye of Sauron turned elsewhere.

It’s human nature to recoil at having something taken away. “Access revoked” doesn’t have a positive ring to it, but maybe we just need better language?

Instead of “access revoked” think “distributed responsibility.”

Instead of “kicked out,” think “focused on your highest-and-best-use.”

As an analyst, you deserve to do your best work — without carrying the burden of enterprise data governance. That’s what I’m here for. Focus on the story your data tells. Call me if you get stuck!

So yes, last month we made the collaborative decision: our analysts now focus on front-end reporting, while governance and data modeling are handled centrally. In doing so, we simplified our documentation, made on-boarding faster, role delegation easier, and satisfied any lingering concerns from compliance. Most importantly, we helped our analysts deliver better results.

I believe this is the best thing we could have done to empower both our organization and our analysts to be successful.