The most expensive thing in your growth org isn't ad spend. It's the three-day wait for a data pull.
That reads like a line built to be argued with, so let me make it concrete. I spent years as the person filing the tickets. I would send the data team a question, wait two or three days, get a clean CSV back — and then not ask the obvious follow-up. Not because the follow-up didn't matter. Because it was worth another three days, and by then the campaign had already finished running.
The cost nobody puts in the deck
When people complain about slow data, they describe the visible cost: decisions arrive late. The answer lands after the moment it was for. That's real, and it's the smaller half.
The larger half is the triage that happens before anyone writes a ticket. You develop an internal price for curiosity. Every question gets silently weighed against three days of someone else's queue, and most of them lose. Not dramatically — you don't sit there mourning the analysis you didn't request. You just move on to the next thing, and the question dissolves.
You don't experience that as a loss. That's what makes it so expensive. You experience it as focus.
And the questions that die in triage are a specific kind. They're the exploratory ones — the ones you can't justify yet, where the honest description is "I have a hunch and I want to poke at it." Those have the lowest expected value per question and by far the highest value in aggregate, because they're the only ones capable of surprising you. When a question costs three days of a colleague's week, you spend it on the question you can defend in a standup. And you can only defend a question when you already half know the answer.
So the system quietly selects for confirmation. Everyone involved is behaving reasonably. The output is a growth org that mostly checks things it already believes.
A dashboard answers a question somebody asked six months ago
The standard response to all of this is to build more dashboards, and dashboards are genuinely good at their job. Their job is answering the question someone anticipated. Weekly numbers, channel splits, the funnel steps you knew to instrument. That work should be automated and it should be one click away.
But almost everything genuinely useful I have found in growth data lived in the third or fourth question of a chain, and no dashboard is built for the third question.
"Which cohort converts best" is a dashboard question.
"Which cohort converts best, excluding the ones acquired on that voucher, in the two weeks after the app update, in cities where we ran no offline campaign" is not a dashboard question. It's a query. And it's the one that changes a decision.
Look at where each of those clauses came from. The voucher exclusion came from noticing something odd in the first answer. The two-week window came from the second. The offline-campaign filter came from an objection someone raised about the third. None of it could have been specified in advance, because the chain didn't exist until somebody walked it.
That's why "we'll add that filter to the dashboard" never closes the gap. You can add any one of those filters. You cannot add the sequence. Do it long enough and you end up with a dashboard carrying forty controls that faithfully answers last quarter's third question, and a team that has stopped opening it.
The cost of slow data isn't the answers you waited for. It's the questions you quietly decided weren't worth asking.
So I learned to write SQL. Badly, at first.
BigQuery first, then Clickhouse. My early queries were bad in every way a query can be bad. I scanned things I had no business scanning. I got numbers wrong, said them out loud, and had to be corrected by someone who had to go and find the mistake for me — which, I am aware, is a worse use of an analyst's afternoon than the ticket would have been.
What changed was not the speed of the answers. I want to be precise about that, because "faster answers" is the obvious benefit and it's the wrong one. Speed mattered only because it changed the price of a question. When asking costs ninety seconds instead of three days, the arithmetic of curiosity inverts.
What actually changed is that I started asking worse questions. Far more of them, most going nowhere. A hit rate that low is completely affordable when the cost per attempt rounds to zero, and completely unaffordable when each attempt spends three days of a colleague's week. The queue wasn't slowing my analysis down. It was setting a minimum quality bar on questions, and the interesting ones couldn't clear it.
This is not an argument against analysts
Good analysts are better at this than I will ever be, and the queue was never a service failure. It existed because the data team was prioritising correctly. Every ticket I filed was competing against work that genuinely mattered more than my curiosity, and it lost on the merits. The three days were the system working as designed.
Which is exactly why you can't fix it by asking them to go faster. You fix it by taking one class of question out of the queue entirely.
There are two kinds of data work and they get confused constantly:
- Questions with a defined output that someone will act on. Attribution models, experiment readouts, anything that becomes a number in a board deck. These need rigour, agreed definitions, and reproducibility. They belong with the data team and they should be prioritised ruthlessly.
- Questions you're asking to find out whether there is a question. Disposable, wrong half the time, occasionally the origin of everything that follows. These belong to you.
Filing the second kind as a ticket is how you end up with a data team that thinks growth wastes their time and a growth lead who thinks the data team is slow. Both of them are right.
"Dangerous" is a lower bar than it sounds
I'm not arguing every marketer should become an analyst. The bar I'm describing is genuinely modest:
- Selects, filters, grouping, and joins you understand well enough to notice when you have silently multiplied your row count
- Knowing which table is the source of truth and which is a derived copy someone built for a project that ended in 2023
- The discipline to check any new number against one you already trust before you repeat it to anyone
- Knowing the point at which to stop and hand it to someone who does this properly
The fourth one took me the longest. Being able to produce a number is not remotely the same as being able to trust it, and a growth lead with query access and no scepticism does more damage than one with no access at all. I have been that person. The confidence arrives well before the competence.
But the model writes the SQL now
Fair. In 2026 you can describe a question in English and get a working query back, and that drops the cost of syntax to roughly nothing. If the argument here were "learn to type SQL," it would already be obsolete.
It isn't. Syntax was never the expensive part. The two things that were expensive are untouched.
The first is knowing which question is worth asking third — which is a function of context, not language. Nothing in your schema knows that the drop you're looking at started the week pricing changed in one market.
The second is knowing when the answer is wrong. A model will cheerfully join two tables at the wrong grain and hand you a clean, confident, entirely fictional number, formatted beautifully. It will not tell you that the events table stopped firing properly after the March release, or that a meaningful share of your organic rows are misattributed, or that this table double-counts refunds. That knowledge isn't in the schema. It's in the heads of four people, and you only acquire it by being close enough to the data to have been burned by it.
So the bar moved. It moved from "can you write a query" to "can you read one and smell when it's lying to you." That second skill was always the one doing the work.
Somebody else's summary
Here is the narrow version of the claim, the one I'd actually defend: a growth leader who can't interrogate their own data is running on somebody else's summary of it. That's fine — genuinely fine, most of the time — right up until the summary is wrong.
And summaries don't go wrong because anyone was careless. They go wrong because every summary is a stack of decisions about what to exclude. Which users count as active. Whether the trial cohort is in or out. What happens to refunds, to test accounts, to the market you launched and paused. Each of those was decided reasonably, often by someone who has since left, in service of a question that was not yours.
You are not being misled. You are being handed a well-built answer to a subtly different question, and nothing in the file tells you which one. The only defence is being able to open it up — not to redo the work, but to know what you're standing on before you bet a quarter's budget on it.
Learn enough SQL to be dangerous. Not to replace your data team, and not to prove anything. To stop rationing your own curiosity.
The ticket queue was never really the constraint. The constraint was that you learned — quietly, reasonably, without ever noticing — to want less.