Most Companies Aren't Data-Driven. They're Engineer-Filtered.

The phrase "data-driven" gets used as if it means "we look at numbers." It almost never means that. What it means at most companies is "two engineers look at numbers and tell the other ninety-eight people what they saw."

That's not data-driven. That's engineer-filtered. And it's a worse problem than it sounds, because the filter is invisible and it's running on every important decision.

How the filter actually works

The data lives in a Postgres or MySQL database somewhere. Five percent of the company can write SQL. Maybe ten percent can read it. The other ninety percent can either:

• File a request and wait somewhere between two hours and four days.
• Look at a stale dashboard built six months ago.
• Guess.

In practice they almost always guess. The cost of the request is too high relative to the value of the answer for most decisions. So they make the call on instinct and call it data-informed.

I've sat in meetings where someone said "I think churn is up this month" and the response was "yeah, mine too" and that was the entire data step in a room that was about to sign off on a quarter-million-dollar campaign. The number was sitting in a table 200ms away. Nobody could reach it.

This isn't a culture problem. The people in the room cared about being right. It's an access problem. The infrastructure made the right answer too expensive to retrieve.

The three real reasons people don't access data

When I push on this with founders, they want to talk about culture. The actual reasons are mechanical:

SQL is a real skill. It takes a few weeks to get fluent and a few months to be reliable. Most people who only need to query the database every couple of weeks don't get reliable, because skills you don't use atrophy. So even people who once knew SQL avoid it.

Direct DB access is a real risk. Engineering is right to be twitchy about handing prod credentials to marketing. One wrong query holds an exclusive lock and the app goes down. One wrong filter exfiltrates a column you don't want exposed. The sane policy is "nobody has direct access" and that policy makes the data unreachable.

The tools assume you're a DBA. pgAdmin, MySQL Workbench, even DBeaver — they assume you know what a connection pool is and that you can read an EXPLAIN plan. They are not designed for the marketing manager who just wants to know last month's signups.

These three together explain almost the entire gap. None of them are about whether the company "values data."

What the answer actually has to do

To close the gap, an access tool has to do three things at once:

It has to translate intent into queries, so the SQL skill ceiling stops mattering for routine questions. The user types "trial-extended accounts that haven't logged in in seven days" and gets correct SQL.

It has to enforce safety at the gateway, so engineering can stop being the guardrail. Read-only by default. Allowlists for tables and columns. PII columns masked from people who don't need them. Row caps and query timeouts at the connection. The agent or the human can ask anything, and the gateway is what decides what runs.

It has to be unintimidating, so non-technical people will actually open it. Search box. List of saved questions. Big "run" button. That's the UI. They aren't writing SQL. They're picking from a list, or asking a question, or running something a teammate already saved.

This is the gap I built QueryBear into. Not because nobody else has done parts of it — Metabase has the UI, Hashicorp's tooling has the gateway concept, Claude already does the natural-language part — but because no one product covers all three at the cost a small team can stomach.

What changes when access actually works

The interesting effect is the meeting effect.

Before: someone says "I think churn is up." Everyone nods. The decision proceeds.

After: someone says "I think churn is up." Someone else opens a saved query, or pastes the question into Claude, and 30 seconds later there's a real number in the room. Sometimes it confirms the gut. More often it doesn't. Either way the next 20 minutes of the meeting are about the actual data instead of the vibes.

Multiply that across every meeting at a 50-person company and the company starts making materially different decisions in three months. Not because anyone changed their values. Because the cost of looking up the number went from 30 minutes and a Slack escalation to 30 seconds and a click.

That's the unlock. "Data-driven" is downstream of "data-accessible."

What I'd do if I were starting this today

If you're a founder reading this and wondering what to ship first, in priority order:

1. Get a read-only role on your prod database, and a connection that goes through a gateway, not a raw URL. Stop sharing prod creds in Slack.
2. Identify the five questions you re-answer every week. Save them as queries with parameters. That alone reclaims hours.
3. Hand a non-engineer a tool that lets them re-run those saved queries with their own filters. Don't make them open a SQL client.
4. Train the team to read SQL, not write it. It takes an afternoon. It pays back forever.

You don't need a data warehouse, a semantic layer, or a hire to do this. You need an access surface that doesn't punish people for asking.

The companies that figure this out are not smarter. They just stopped letting the engineer-filter run.