If you are a senior engineer on a small data team and you want to work on strategy, you have two places to learn it from, and on a team your size both of them steer you wrong. There’s your own engineering experience, where a better argument wins the design review, and there’s everything you can read about data strategy, which is written for a company with a Chief Data Officer, an executive sponsor and a budget line for every pillar of a maturity model.
You likely work somewhere where the people who sign off on your plan are the same people who send you report requests, and nobody has the job of explaining the data team to anyone.
A small team runs a real data strategy with none of the enterprise bureaucracy, and the part it can’t skip is selling it, and that’s the part engineers skip first.
On a small team, selling the plan is part of the plan
People are emotional and stupid. That includes you, me and every senior manager who signs off on a data plan. I do stupid shit all the time, and so do you.
So your senior managers decide on how a plan feels, and a plan explained in steps and numbers feels like a cost with an attached timeline.
Engineering trains the opposite reflex into you. In a code review the better argument usually wins, so you learn that being right is enough, and then you bring that habit into a planning meeting where nobody is reviewing your logic line by line.
My own version is the MongoDB story, where I gave the founder at the next desk the technical answer when he wanted the business one and lost his trust for months.
Even the biggest data organizations say people are the hard part. In the 2025 survey by Randy Bean’s Data & AI Leadership Exchange, 91.2% of executives from 125 Fortune 1000 and leading global companies named culture and change management as the principal challenge to becoming data and AI driven, against 8.8% who named technology.
In companies like those, somebody else does most of the selling. A sponsor pitches the plan upward, champions keep the other departments on side, and a comms team explains what each release was for.
Your team of five has none of that, so every one of those jobs is yours, or your manager’s, retelling your pitch from memory in a meeting you’re not in.
On a small team, nobody sells your strategy for you.
So the pitch is part of the strategy. You write it at the same time as the plan, and you write it yourself.
Sell where you’re going, and keep the plan honest
This is where you have to think like a marketer, which I know sounds terrible to an engineer. Your plan is a list of steps and what each one costs, and you already know how to write it. Next to it you need a picture of the company once those steps are done, the finance team that stops rebuilding the same spreadsheet every Monday, the product manager who gets an answer the same afternoon.
You need to wrap it up in a shiny package. They need to dream about the future you sell.
The picture and the plan do different jobs, and mixing them up is how this goes wrong.
The plan says what’s true today, what’s broken, what you do next and roughly how long it takes, constraints included.
The picture says where that leads. When the picture promises more than the plan delivers, the first delivery is where you lose them, because everyone compares what shipped with what they imagined, and the gap costs you the next yes.
Retell it every time you ship
Once you start shipping, nobody connects that to your plan unless you connect it for them. Something that’s step 2 of migrating Finance away from spreadsheets looks like a ticket closed on Tuesday ot others.
When nobody makes that connection, every new request starts from zero, the next step has to be argued for from scratch, and the strategy dies without anyone ever deciding to kill it.
The fix is to name the step and where it sits in the space-time continuoum. Something like “This closes step 2 of getting finance off spreadsheets, and step 3 starts on Monday“.
Train them and remind them, until your manager says it back to you in a meeting without being asked.
A Big Tech stack comes with Big Tech’s pace
Engineers are the most exposed to this one, because most of us learned what good looks like from Big Tech engineering blogs. I keep hearing some version of “If it works for META, there’s no reason why it wouldn’t work for us“, and I argued against it in the past.
Implementing their tools forces you to work their way.
Their way assumes a team with people to run each piece, and months of setup before anyone outside the team sees a result. A small team that spends those months standing up Databricks, Airflow and Alation has not a damn thing to show the CFO at the end of them, so the story you’re meant to retell every time you ship has nothing in it.
There are alternatives. A small team gets going in a day with PostgreSQL, Orchestra and a page in the Confluence wiki, or with whatever lighter option you prefer. Big tools and small tools both run a strategy fine, as long as you know what you need and where you are.
Big Tech has different problems from the ones most of us have, starting with how much data there is. Jordan Tigani wrote that “the vast majority of customers had less than a terabyte of data in total data storage“. Weigh the source, and then look at your own warehouse.
Knowing where you are comes down to three answers, before you pick the heavy option.
What business need does it meet, and who named it?
What waits while you set it up?
Who runs it once it’s live?
Sometimes the heavy option is right. Our ELT migration took both engineers, the whole data team at the time, for months while everything else waited, and it was still the right trade because the business needed raw data faster than our transform layer could deliver it.
What the heavy option costs to keep running is a separate bill, and I’ve already talked about this, too.
Your strategy fits on two pages, and most of it stays with you
If you’ve been reading enterprise strategy advice, or you come from academia or a big company, it’s easy to confuse strategy with compliance.
Strategy exists to move you forward, and compliance is meant to slow you down.
A long strategy document exists so that hundreds of people who never talk to each other work toward the same thing. Your team of five does that on one call, so a long document written for your team is written for readers who don’t exist.
Maturity models, Gantt charts and a 10-year plan circulated to the whole senior team are compliance work.
Screw all this bullshit!
Bernard Marr’s data strategy template says “a one-pager is never going to be detailed enough“, and for a company with a CDO and a strategy office he’s probably right.
The one number I have on whether long plans pay off points the other way. ClearPoint looked at 20,582 plans on its own platform and says “organizations that spend six months on SWOT analysis and stakeholder workshops have roughly the same on-track rates as those that hammer out a plan in a two-day retreat“. Those are general business plans, not data strategies, and the vendor has a stake in the answer.
What’s left fits on one or two pages of a Google doc.
Where you’re going, in a sentence or two
The next few steps, and why those come first
Roughly how long each one takes
What waits while you do them
Now, I say steps on purpose. It’s rarely a single project, and it doesn’t need to be a detailed project plan either, because how much detail goes in depends on who reads it. If you want a structure for filling the two pages, the five decisions work.
For your own case, the ready-to-use version is my digital twin, and it comes with the annual subscription.
Ideally you write it and keep working on it, and it stays a document for you. Your senior managers get the story you sell them and the next steps, with as much detail as they need to say yes.
The bigger the company, the more experienced senior managers you have, and the more clarity they need. A founder at a small startup hears “finance numbers first, then the product dashboards” and has enough, while a larger company’s senior managers want the steps split out with owners and rough dates, and that’s a fair ask.
Final thoughts
Less bureaucracy on small teams is the whole idea, and I believe it. I also believe the two pages get longer as the company grows, and somewhere along the way clarity turns into the compliance I just told you to screw. I don’t know where that line is, but it isn’t anywhere near a team of five.
What I’d do this week is smaller than any of that. Write the two pages, keep the document to yourself, and tell the first person whose yes you need where the next few steps lead, in a sentence they could repeat to someone else without you there.
—
Until next time,
Yordan
PS: If you want my answer to your own version of this before you have to give yours, subscribe for the year and ask my digital twin, which answers the way I would.
PPS: Today is the last day before I raise the subscription price significantly. Upgrade while you still have the chance.
The 91% vs 9% stat says it all. Engineers learn that the better argument wins, then walk into a planning meeting where nobody's reading the argument. Small teams feel it most, because there's no sponsor doing the selling for you.