👷 How to Build a Data Strategy Without Buying a Single Tool
All you need is to answer these 5 questions to set your org for long-term success
Thank you to Cube for sponsoring this issue of Dat Gibberish. Check the link below to learn more.
I built a live chat feature on MongoDB when the company already ran on MySQL for everything else.
I told myself it was the right call. Chat data is unstructured, MongoDB handles that better, and everyone on LinkedIn was writing about document stores as the future. I also had a quiet thought I never said out loud, that this would look good on my CV.
The founder sat on the desk next to mine. He asked why we needed to introduce a new piece of technology, and I gave him the technical answer when he wanted the business one. Over the next few months, he stopped asking my opinion on decisions he used to loop me into, and I earned that. I was building for what felt like the future, or what felt impressive, or what felt safe against some imaginary scale we were nowhere near, not for the business in front of me.
It took me years and a couple of good mentors to unlearn that habit. Once I did, the same instincts that picked MongoDB for the wrong reasons picked our move from Redshift to Snowflake, our shift from ETL to ELT, and the status page that ended our incident-question flood, for the right ones. That shift took me under four years from data engineer to head of data engineering. I have been writing strategy documents for close to a decade now, and the framework underneath all of them is simpler than anyone selling you a maturity model wants you to believe.
This issue is brought to you by Cube.
Agents do the analysis. Your team does the thinking.
A question about your own business data still means a ticket, a queue, and a week of waiting. Cube hands that workflow to AI agents: they model the data, explore it, and build the reports — your team guides and approves — so week-long analysis comes back in minutes. And because every agent works from one governed set of metric definitions, the answers come back right. 400+ companies run on Cube, including Brex, Wix, Patagonia, and Webflow.
What Everyone Calls a Data Strategy
Ask ten data teams what their strategy is and most will name a tool.
“Our strategy is moving to Snowflake“
“Our strategy is finally adopting AI“
“Our strategy is switching to data mesh“
Those are purchases wearing a strategy costume, the same mistake I made with MongoDB when I picked a tool and backfilled a reason for it instead of starting from a reason and letting the tool follow.
This especially bites small and mid-sized teams. You don’t have the headcount or the runway to recover from a wrong bet the way a 10,000-person company can. Data Mesh proves the point: only 10% of companies under 50 employees adopt it, against 27% of large enterprises, while 43% of small teams centralize around a single warehouse compared to 29% of enterprises, per the 2026 State of Data Engineering Survey by Joe Reis. Small teams already apply real-gap thinking to architecture. The habit just hasn’t spread to every other tool decision yet.
Search “data strategy“ and you’ll find the same pattern from consultancies and platform vendors, long guides on maturity models and governance frameworks that confidently define what a data strategy is while skipping the five decisions that actually produce one.
What a Data Strategy Actually Is
A data strategy is the connection between where the company is going and the specific data infrastructure, pipelines, and capabilities you fund to get it there. It’s not a tool, and it’s not a slide of principles. It’s an answer, backed by a real price tag, to what data capability the business needs and how you’re closing the gap between that and what you can actually deliver today.
You get to that answer by working through five decisions, in order:
Where the company is actually going
What that growth demands from data specifically, in volume, speed, sources, and metrics
Where your current data infrastructure falls short of that demand today
The portfolio of data projects that closes the gap
The price of each project
Skip any one of the five and you get a tool decision masked as a strategy. I skipped the first step for years without realizing it.
Here’s how to build it step by step:
1. Where The Company Is Actually Going
Most engineers and tech leads don’t know where the company is headed in the next 12 to 24 months, and that’s not a personal failure. Nobody hands you that information by default, and most technical roles are structured so you never have to ask for it.
It’s your manager’s job to know this, or to go find out, since that’s part of what they’re paid for. If you don’t have this information, ask for it instead of guessing.
Bring this into your next 1:1: ask what the business needs to be true in 12 months, and what changes for the team if it happens. If your manager doesn’t have an answer, that’s useful information too. It tells you the gap starts above your team.
Don’t skip this step if you aim and building your data strategy at any capacity.
2. What That Growth Actually Demands From Data
This is where “what if we suddenly had 100,000 users“ belongs, and where I used to get it wrong. The instinct to plan for scale isn’t wrong, only pointed at a number you invented instead of one the business gave you.
A semantic layer is a good test case for how this is supposed to work. A year ago, teams argued over whether a standalone semantic layer was worth it for a small setup. Adoption has since tripled, from roughly 8% to 28%, and none of the data leaders tracked in the latest survey still question its value, per Hex’s State of Data Teams report. The debate ended because the demand became real: too many teams needed one place where a metric meant the same thing everywhere.
Once you have a real growth target from step one, translate it into what it demands from data:
How much volume?
How fast the data needs to move?
Which new sources show up?
Which metrics the business will start asking for that don’t exist yet?
Every one of those demands has to trace back to something the company actually said. Do not assume.
3. Where You Fall Short Today
This is the step where the founder lost trust in me. The gap between what I built and what the business needed wasn’t technical, since I was already a strong engineer. The real gap was that my decisions and the company’s needs had stopped lining up, and I couldn’t see it because I never checked.
Name your gaps against the real demands from step two, not against what feels outdated or what a blog post said was falling behind. A tool can be old and still be exactly right for the demand in front of you.
4. The Portfolio of Projects That Closes The Gap
A strategy is the full set of projects required to close every gap you named in step three, not one project picked on its own.
Small teams that get this right tend to converge on the same kind of tools. Dagster shows almost four times the adoption in companies under 50 employees, 11%, compared to large enterprises at 3%, not because it’s trendy, but because it fits the orchestration gap a small team actually has, low administrative overhead over more knobs to turn. Meanwhile, more than 20% of data professionals surveyed still run with no orchestration at all, per the 2026 State of Data Engineering Survey, which is usually a sign nobody has walked through steps one to three yet.
This is what it looked like for me once I started doing this the right way:
Redshift to Snowflake, because concurrent query demand from a growing analytics team was hitting a real ceiling, not because Snowflake was trending
ETL to ELT, because the business needed raw data available faster than our transform layer could keep up with
The status page, because stakeholder trust was breaking down over incident visibility, the same kind of trust I’d already lost once with the founder
Each project closes a named gap, not a line I wanted on my résumé.
5. The Price of Each Project
This is the step that turns a strategy into a plan, because every project on your list competes with every other project for the same headcount and the same hours.
The ELT migration cost us months of both engineers’ full attention, the entire data team at the time, and for a while it was the only thing getting worked on. There was nobody else to pick up anything else, so everything else waited, including things I wanted to build. That was the right trade, because the demand it closed mattered more than what it delayed. But it was still a real cost, and pretending otherwise would have made the next prioritization conversation dishonest.
Name the price before you commit:
Budget
Headcount
Time
What you deprioritize to fund it
If you can’t name what you’re giving up, you haven’t actually decided anything yet. Small and mid-sized businesses that adopted cloud computing and modern data infrastructure saw 19% higher turnover per worker, even after controlling for company size, per GOV.UK’s Business Data Use and Productivity Study. That’s the return on doing the work instead of buying the tool that looks good on a slide.
I turned this exact five-step framework into a worksheet, one section for each step above, so you can run your own team’s data through it instead of mine. Grab the worksheet here and fill it in against a real goal your company has right now, not a hypothetical one.
Why Maturity Models Are Useless for Most of Us
Every top-ranking article on “data strategy“ leans on the same shape, a maturity model with four or five pillars, usually governance, architecture, people, and technology, each staffed by a dedicated owner and reviewed on its own cadence. McKinsey and Gartner built this model for a client with two hundred people in the data org and a budget line for each pillar, but this is is rarely the case for data teams in 2026.
If you’re running a team of two, or five, or even fifteen, data strategy is something completely different. You have no governance lead, no architecture review board, and no spare headcount, only you, maybe one other engineer, and a backlog that never gets shorter. Running a four-pillar maturity model on a team that size spends a whole quarter drawing a framework nobody on the team has the headcount to staff, instead of adding any real rigor.
Most of that content is bullshit for a team our size. The five decisions in this article are what’s actually left once you strip away every part of the enterprise version that assumes resources you don’t have.
Final Thoughts
A lot of data leaders fall for this at scale, not only individual engineers. The share naming AI their #1 priority jumped from 4% to 27% in six months, per Hex’s State of Data Teams report, and for plenty of them, AI became the strategy by default, a company-wide bet made because of the hype, not because anyone ran it through five decisions.
I’d guess an equal number work inside companies making that exact bet and recognize it for what it is. Experienced data leaders treat the mandate as the demand in step two, not something to fight, and build the actual gap-closing projects underneath it, the four decisions the company skipped, for their own team.
After seeing the this kid of tool-driven strategy many times in the past, and even making the same mistake myself, I find this “spray and pray” approach ridiculous. Obviously, you can get lucky, but luck is not enough when you are trying to build long-term career and business.
That said, I strongly encourage you to use AI and build AI-powered projects. There’s is value in this, but you need to avoid putting all your eggs in the same basket. At the end of the day, your job only matter for the business if you help it make more money, save costs or avoid risks.
—
Until next time,
Yordan
PS: Want to learn how to think and behave like a leader and actually deserve your promotion? Upgrade today.